这可能是一个愚蠢的问题，但由于我目前正在阅读的 ASP.NET MVC 书，我感到困惑......
使用 Linq-To-SQL 似乎说将 Linq-to-SQL 对象直接传递给 Controller 不是一个好习惯，但是每个对象应该首先单独建模，并且应该在 Controller 和存储库。
比如说，我有一个产品数据库。 Linq-to-SQl 为我创建了一个具有 Name、Price 和 Whatnotelse 属性的产品类。我可以将它直接从存储库传递到 Controller 然后查看，但它似乎建议我使用第三类，比如 Product_Entity，还有 Name、Price 等属性并将其传递给 Controller 。
我没有看到这种方法的好处，除了可能为属性添加属性……但除此之外，它似乎弊大于利。假设每个产品也有制造商信息，我不知道如何在第三堂课中轻松建模。
这种方法真的是最佳实践吗？还是我误解了这一切？如果是这样，为什么直接关闭 linq-to-sql 生成的对象会很糟糕？以及如何处理 y 中对象之间的关系
最佳答案
您创建的另一个类的巨大好处是，使用您的示例，它不一定映射到产品或制造商。像这样思考:
让我们举个例子。假设在您的 MVC 应用程序中您想显示有关产品的信息网格。您想查看他们的名称、价格(来自产品表)以及他们的制造国和制造商名称(来自制造商表)。你会给这个类起什么名字？产品_制造商？如果稍后您想从第三个表(例如产品折扣)中添加属性怎么办？不要在纯粹的数据域中考虑这些对象，而是从您的应用程序中考虑它们。
因此，不是 Product_Manufacturer，而是将其称为 ProductSummaryItem 怎么样？ ProductSummaryItem 类的每个属性将 1:1 映射到 UI 网格中显示的字段。您的 Controller 将执行数据域(产品、制造商)中的信息与您在应用程序域中创建的自定义类 (ProductSummaryItem) 之间的映射。
通过这样做，你会得到一些很棒的好处:
1)写你的观点变得非常非常简单。显示数据所需要做的就是循环遍历 ProductSummaryItems 并将它们包装在 和 标签中，然后就完成了。它还允许简单的聚合。例如，假设您想向 ProductSummaryItem 类添加一个名为 ProductsSoldLastYear 的字段。您可以在您的 View 中非常简单地做到这一点，因为对他们来说，这只是另一个属性。
2) 由于 View 是微不足道的，并且 Controller 中有映射逻辑，因此测试 Controller 的输出变得更加容易，因为它是针对 View 将要看到的内容进行定制的。
3) 由于 ProductSummaryItem 类只有它需要的数据，您的查询可能会变得更快，因为它们只需要查询将填充您的 ProductSummaryItem 对象的字段，而不需要其他任何内容。构成 ProductSummaryItem 对象的数据域对象越多，这种开销就会变得很大。
这种模式被称为 Model View ViewModel (MVVM) 并且在 MVC 以及 WPF 等框架中非常受欢迎。
反对 MVVM 的论点是您必须为 CRUD 操作重新实现一些简单的类。我想这很公平，但您可以使用像 automapper 这样的工具。帮助解决类似的事情。不过，我认为您很快就会发现，即使对 CRUD 使用 MVVM 模式也会带来好处，因为在您知道之前，即使使用简单的类，您也会开始希望拥有可以轻松驱动您的 View 的额外字段。
关于asp.net-mvc - 最佳实践问题 - 直接使用 Linq to sql 类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7072605/