asp.net-mvc – 最佳实践问题 – 直接使用Linq to sql类

>您的Linq to SQL类用于在“数据”域中进行通信.
>您的“数据”类(您遇到问题的类)用于在“应用程序”域中进行通信.

我们来举个例子吧.假设在您的MVC应用程序中,您想要显示有关产品的信息网格.您希望查看其名称,价格(来自产品表)及其制造国和制造商名称(来自制造商表).你会为这堂课命名什么？ Product_Manufacturer？如果您以后想要从第三个表中添加属性(如产品折扣)怎么办？而不是在纯粹的数据域中考虑这些对象,而是根据您的应用程序考虑它们.

因此,而不是Product_Manufacturer,那么将其称为ProductSummaryItem呢？ ProductSummaryItem类的每个属性都将以1：1的形式与UI上的网格中显示的字段进行映射.您的控制器将执行数据域(产品,制造商)中的信息与您在应用程序域中创建的自定义类(ProductSummaryItem)之间的映射.

通过这样做,您可以获得一些非常好的好处：

1)写你的观点变得非常非常简单.要显示数据所需要做的就是遍历ProductSummaryItems并将它们包装在标签中,然后就完成了.它还允许简单的聚合.比如说你想在ProductSummaryItem类中添加一个名为ProductsSoldLastYear的字段.你可以在你的视图中非常简单地做到这一点,因为它们只是另一个属性.

2)由于视图很简单并且控制器中存在映射逻辑,因此测试控制器的输出变得更加容易,因为它可以根据视图的内容进行自定义.

3)由于ProductSummaryItem类只具有所需的数据,因此您的查询可能会变得更快,因为它们只需要查询填充ProductSummaryItem对象的字段,而不需要查询其他内容.构成ProductSummaryItem对象的数据域对象越多,这种开销就越大.

这种模式称为Model View ViewModel(MVVM),并且非常受MVC以及WPF等框架的欢迎.

针对MVVM的论点是你必须在某种程度上重新实现CRUD操作的简单类.我想这很公平,但你可以使用像automapper这样的工具来帮助解决这类问题.我认为你会很快发现,即使对于CRUD使用MVVM模式也会带来好处,因为在你知道它之前,即使是简单的类,你也会开始希望你有额外的字段可以轻松地驱动你的观点.