LINQ 实体作为业务对象 - 优点/缺点答案

【问题标题】：LINQ Entities as business objects - pro/consLINQ 实体作为业务对象 - 优点/缺点
【发布时间】：2009-05-26 18:30:33
【问题描述】：

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

谢谢

【问题讨论】：

你不是刚刚回答了你自己的问题吗？您没有将数据库设计为域模型（我希望如此），并且这些“实体”直接映射到您的数据库表，这意味着它们直接映射到您的“非域模型”。我认为这是回答“不”的理由。
John Saunders，实体框架模型，与 LINQ to SQL 不同，不需要（实际上通常也不应该）直接映射到 DB 架构。

【解决方案1】：

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

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

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

【讨论】：

我完全同意，我遇到过很多程序员以与他们查看 SQL 相同的方式查看 Linq。他们认为应该将其包装在“DAL”中，而不是将其视为 DAL 本身！我希望人们开始了解 Linq 是 BL 和 SQL 之间的层。

【解决方案2】：

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

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

马克

【讨论】：

+1 建议使用实体框架。听起来它可能是你的胡同。

【解决方案3】：

视情况而定

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

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

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

【讨论】：

【解决方案4】：

我认为这取决于场景。

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

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

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

【讨论】：