LINQ实体作为业务对象 - 利弊

Question

Visual Studio（sqlmetal）生成的dbml文件带有映射到数据库表的实体。在您看来，这些条款适合用作域模型类？或者我们应该避免它们并将它们隔离到数据访问层中吗？

由于

Answer 1

在大多数情况下，实体对象和编写SQL 之间的含糖良好层是您的DAL。 LINQ的全部目的是让你的DAL表达比过去更多的表达结构。

如果没有LINQ，在您的BL中，您可能仅限于针对DAL的方法调用，例如GetCustomersByLastName(string)。您编写该方法的唯一原因是因为BL中的某个位置，您需要通过姓氏获取客户。这意味着您的DAL合同是由BL的需求明确驱动的。而使用LINQ，您可以摆脱BL的需求与DAL合同之间的具体依赖关系。对于特定用途，DAL可以完全不可知;它只是暴露了实体的合同及其关系，而且BL随意使用它们而不关心它们的数据实现。这是真正的关注点分离。

如果隐藏传统DAL背后LINQ的强大功能，那么使用LINQ有什么意义呢？

Answer 2

对于一个足够简单的应用程序，直接使用LINQ实体的一大优点是 - 简单。您可以避免在代码中使用Yet Another Layer，您可以避免编写大量样板逻辑来从业务对象映射到LINQ实体（尽管有AutoMapper这样的工具可以帮助很多）

另一方面，正如您所说 - 您的数据库可能不是您的域模型的随地吐痰图像。然后，如果您需要此功能在给定的物理数据库模型和逻辑域模型之间进行映射，那么您应该查看实体框架吗？这正是EF的主要支柱 - 这两个模型以及它们之间的映射层。

马克

Answer 3

取决于

如果您的域对象非常简单且您的项目很小，那么使用这些类不是问题。编写一个只重复这些类的整个额外层将是浪费时间。

如果对象复杂并且没有以前瞻性方式进行映射，则另一层对于将这些细节与数据访问层分离至关重要。

如果你真的不确定，你可以直接开始使用它们，然后一旦明显你需要它就添加另一层。

Answer 4

我认为这取决于场景。

我现在正在编写一个WCF服务，我的数据模型不是很复杂，但是所有表都有外键和表之间的关系使得linq创建了一个非常复杂的对象树。

从客户端的角度来看，检索所有这些对象树是没有意义的，而且返回的xml消息也很重（所以如果我不改变消息大小最大允许值，我会得到错误）。

在这种情况下，我不得不在LINQ对象上创建自定义视图，只返回期望检索的数据客户端。这是一个非常痛苦的事情，因为我不得不重写大多数实体，但最终我完全控制了与客户的沟通。