在过去的几周里，我一直在研究MVC 4.0，并试图看看是否要从Web表单切换到MVC。
我目前的生产环境是： 1）一个主数据库，具有3个独立的asp.net Web表单应用程序（调度程序，销售报告，中央管理），可与之通信 2）这个主数据库不包含适当的外键，对当前应用程序使用了大量的存储过程，结构也可能使用了一些重新设计，但它的'我继承了一些遗留系统＆amp;代码。
当我开始为改进的销售报告应用程序创建原型时，我开始遇到一些问题，我不得不使用Visual Studio中的迁移工具不断修改数据库。我发现表之间的关系没有正确建立，因此使用实体框架更具挑战性。
我绝不是MVC专家和实体框架专家，但我已经开始质疑我是否应该利用我现有的情况进入MVC。最让我害怕的是我在测试环境中必须进行的数据库更改量，以便为我的控制器和视图启用正确的模型。随着我进行这些更改，我觉得其他3个Web表单应用程序必须正确地重新测试，我们没有资源。我们在master数据库或Web表单应用程序中承担不起任何错误，因为这些是面向客户的。
我不介意MVC的学习曲线，我觉得它很有趣，我的经理并不关心我使用的是什么，并且不反对我学习asp.net的扩展。我想有一个时间表，但不是具体的。
我只是接触可能遇到过类似情况的其他人。我的担忧有效吗？我应该坚持使用其他网络表单应用程序还是应该进入MVC世界？
答案 0 :(得分：3)
取决于应用程序层的分离程度。如果您有可靠的服务层来处理所有数据访问并且只是来回传递域对象，那么转换到MVC实际上并没有那么糟糕。在标准的ADO.Net后端拥有MVC前端非常可行。
根据数据库的结构，除非实施所有适当的约束，否则尝试使用EF将很困难。除非您的数据库设置正确，否则EF甚至无法工作。
如果你想转向MVC，我建议分阶段进行。
在将UI转换为MVC时，创建模型以复制数据库表，然后将其传递给UI而不是直接撤回。这样，当您转换为EF时，您已经拥有了正确的模型，您的UI层将不受更改的影响