.net - LINQ 实体作为业务对象 - 优点/缺点

Question

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

谢谢

Answer 1

在大多数情况下，实体对象和编写 SQL 之间的甜蜜层是您的 DAL。LINQ 的全部目的是允许您的 DAL 比过去更富有表现力的构造。

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

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

Answer 2

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

另一方面，正如您所说 - 您的数据库可能不是您的域模型的吐痰图像。再说一次，如果您需要这种能力在给定的物理数据库模型和逻辑域模型之间进行映射，也许您应该看看实体框架？这正是 EF 的支柱——这两个模型以及它们之间的映射层。

马克

Answer 3

这取决于

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

如果对象很复杂并且不以一种严格的方式映射，那么另一个层对于将这些细节与数据访问层分开是必不可少的。

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

Answer 4

我认为这取决于场景。

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

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

在这种情况下，我必须在 LINQ 对象上创建自定义视图，以仅返回客户端期望检索的数据。这很痛苦，因为我不得不重新编写大部分实体，但最终我可以完全控制与客户的沟通。