2

在过去的几周里，我一直在研究 MVC 4.0，并试图看看是否要从 Web 表单切换到 MVC。

我当前的生产环境是：1）一个主数据库，有 3 个单独的 asp.net Web 表单应用程序（调度程序、销售报告、中央管理）与之通信 2）这个主数据库不包含适当的外键，使用许多当前应用程序的存储过程，该结构可能也需要重新设计，但它是我从一些遗留系统和代码继承的。

当我开始为改进的销售报告应用程序创建原型时，我开始遇到一些问题，我必须使用 Visual Studio 中的迁移工具不断修改数据库。我发现表之间的关系没有正确建立，所以使用实体框架更具挑战性。

我绝不是 MVC 专家和实体框架专家，但我已经开始质疑是否应该以我现有的情况跳入 MVC。最让我害怕的是我必须在我的测试环境中进行大量的数据库更改，以便为我的控制器和视图启用正确的模型。随着我进行这些更改，我觉得其他 3 个 Web 表单应用程序将必须进行适当的重新测试，而我们没有资源。我们无法承受主数据库或 Web 表单应用程序出现任何问题，因为它们是面向客户端的。

我不介意 MVC 的学习曲线，我确实觉得它很有趣，我的经理不关心我使用什么，也不反对我学习 asp.net 的扩展。我想有一个时间表，但不是具体的。

我只是在联系可能遇到类似情况的其他人。我的担忧有效吗？我应该坚持使用另一个 Web 表单应用程序还是应该推进 MVC 世界？

4

1 回答 1

3

取决于应用程序层的分离程度。如果您有可靠的服务层来处理您的所有数据访问并且只是来回传递域对象，那么您转换到 MVC 实际上并没有那么糟糕。在标准的 ADO.Net 后端上有一个 MVC 前端是非常可行的。

根据数据库的结构，除非所有适当的约束都到位，否则尝试使用 EF 将很困难。除非您的数据库设置正确，否则 EF 甚至无法工作。

如果您想迁移到 MVC，我建议您分阶段进行。

  1. 如果还没有，请将您的 UI 层与服务层分开。
  2. 将您的 UI 层转换为 MVC。
  3. 当您对 UI 感到满意时，您可以开始更改数据库并将您的数据访问层转换为 EF。

当您将 UI 转换为 MVC 时，创建模型来复制您的数据库表，然后将它们传递给 UI，而不是直接拉回。这样，当您转换为 EF 时，您将拥有正确的模型，并且您的 UI 层将不受更改的影响

于 2013-05-14T05:02:44.383 回答