这可能是一个愚蠢的问题,但由于我正在阅读的ASP.NET MVC书籍,我感到困惑…

使用Linq-To-SQL似乎可以说将Linq-to-SQL对象直接传递给控制器​​并不是一个好习惯,但是每个对象应该首先单独建模,这应该在控制器和控制器之间传递.库.

说,我有一个产品数据库. Linq-to-SQl为我创建了一个具有Name,Price和Whatnotelse属性的产品类.我可以直接从存储库传递到控制器,然后查看,但它似乎建议我使用和第三类,比如Product_Entity,还有Name,Price等属性并将其传递给控制器​​.

我没有看到这种方法的好处,除了可能为属性添加属性……但除此之外它似乎有更多的缺点而不是好处.假设每个产品都有制造商信息,我不知道如何在我的第三课中轻松地建模.

这种方法真的是最好的做法吗？或者我误解了这一切？如果是这样,为什么直接从linq-to-sql生成的对象开始工作呢？你如何处理y中对象之间的关系

最佳答案 您创建的其他类的巨大好处是,使用您的示例,它不一定映射到产品或制造商.想想这样：

>您的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模式也会带来好处,因为在你知道它之前,即使是简单的类,你也会开始希望你有额外的字段可以轻松地驱动你的观点.