我的生产环境中的MVC vs WebForms

在过去的几周里，我一直在检查MVC 4.0，并试图确定是否要从Web表单切换到MVC。我的生产环境中的MVC vs WebForms

我目前的生产环境： 1）一个主数据库，与它 2）通信。这master数据库中不包含3个独立的asp.net web表单应用程序（调度，销售报告，中央行政）适当的外键为当前应用程序使用了大量的存储过程，但该结构可能也会使用一些重新设计，但它的'我继承了一些遗留系统代码。

当我开始为改进的销售报告应用程序创建原型时，我开始遇到需要使用Visual Studio中的迁移工具不断修改数据库的问题。我发现表格之间的关系没有正确建立，所以使用实体框架更具挑战性。我并不是一个MVC专家和实体框架专家，但我开始质疑我是否应该跳入MVC中，以适应现有的情况。最让我感到害怕的是我在测试环境中必须为我的控制器和视图启用正确模型的数据库更改数量。随着我进行这些更改，我觉得其他3个Web表单应用程序必须进行适当的重新测试，我们没有资源。在主数据库或Web表单应用程序中，我们承受不了任何问题，因为这些都是面向客户端的。我不介意MVC的学习曲线，我确实发现它很有趣，我的经理并不在乎我使用什么，也不反对我学习asp.net的扩展。我想有一个时间表，但不是具体的。

我只是向可能遇到类似情况的其他人伸出援助之手。我的顾虑是否有效？我应该坚持使用另一个Web表单应用程序还是应该推进MVC世界？

来源

2013-05-14 foop

你的担忧绝对有效，事实是，无论改变底层框架与之合作将要求更改数据库结构，至少小数据库结构。但是，您可以使其工作，但这将是困难和耗时的。这完全取决于您可以使用的资源类型以及您需要如何修改当前的应用程序库。 – Nomad101 2013-05-14 04:30:01

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

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

如果你想转移到MVC，我会建议分阶段进行。

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

在将您的UI转换为MVC时，创建模型来复制数据库表并将其传递给UI，而不是直接将其拖回。这样，当你转换为EF时，你将已经拥有正确的模型，你的UI层将不会受到这些变化的影响

来源

2013-05-14 05:02:44 Slick86

现在我创建了我的模型并更新了我的数据库结构，但是我一直在发现我需要创建另一个类，我称之为“ViewModel”，它只包含我想更新的属性，甚至将多个模型返回到视图。不太清楚UI层和服务层的分离意味着什么？ – foop 2013-05-14 13:11:47

您希望您的UI层仅以格式化的方式显示数据。您需要一个服务层来负责处理新/更新项目的验证以及从数据源获取所需的数据。在实现这个时，你不希望你的控制器（或者web表单中的代码隐藏）直接访问你的数据库。它会通过一个处理它的服务。根据您的表单设置方式，您可以实际使用表示数据库表的类作为视图模型，然后您不必为此专门创建模型。 – Slick86 2013-05-14 19:51:53

感谢您的意见 – foop 2013-05-15 14:57:57

我的生产环境中的MVC vs WebForms

回答

相关问题