如何实现 DDD 存储库来处理具有多个实体的查询？

我正在努力在 .net 解决方案中使用 DDD 来实现需求。我会尽量减少细节：

实体：

• 类别（UId、名称）
• 属性（UId、名称、属性值[]）
• 属性值（UId、名称、ParentAttributeUId）
• 进程（UId、名称、属性值[]、类别[]）

数据模型：

• 每个进程可以有多个类别（例如 ProcessCategoryMap 表）
• 每个进程可以有多个 AttributeValues（例如 ProcessAttributeValue 表）
• 类别、属性、属性值之间没有关系

我有一个 s.p. FetchByCategoryAndAttributeValues(CategoryId, AttributeValueIds []) 返回一个数据集：

• 与 CategoryId 和 AttributeValueIds 匹配的进程列表
• 可用于细化搜索的 AttributeValues 列表。

如何实现存储库加上调用SP的方法，当返回多个实体时，在我看来，返回的对象是一个值对象，并且似乎不适合现有的实体存储库？

有任何想法吗 ？

Regards,

Pedro

==== 编辑：2011/03/30 下午 02:52 世界标准时间 ====

我正在更新我的问题，以重视所有评论并帮助面临类似挑战的其他人。

@正义：

解决方案：使用 ORM，例如NHibernate 以及使用 ORM 的所有理由

我不记得 Eric Evans 的 ddd 书中提到过 ORM。选择特定的持久性技术有何重要意义？一旦您整理好域名，您就可以按照您希望的方式自由保留它。当然，我知道 NH 可以提供帮助并且是一个强大的工具，但它本身并不是一个解决方案。

@多米尼克/@正义：

解决方案：远离存储过程。

首先，对我来说，当我看到好的 T-SQL 存储过程时，很难证明其合理性，我不是在谈论 CRUD 或简单的 T-SQL 查询。我提到的 SP 运行一些 TSQL CTE，结合来自不同表的指标数据来计算权重，使用临时表并返回客观结果：进程列表、类别列表、属性值列表。 SP针对特定的SQL数据库/服务器进行了优化和调整，可以是MSFT、Oracle等。我不相信将这些计算转移到应用程序端，然后依赖于ORM将有助于缩短执行时间并转发查询。对我来说，在服务器中完成所有这些操作和仅引入过滤后的数据有很大的不同。我可能是错的。

@全部： 我已经确定了真正的问题（就像 Domenic 通过 ayende 链接指出的那样），我正在将基于数据中心方法的解决方案移植到域模型方法。让我们把这个放在一边，SP 返回的计算会影响不同的模型。由于数据在数据库中的持久化方式，存在常见的计算，并且计算在实体之间受到限制，因此问题是在转向 DDD 实现时如何充分利用这两种实现。以及如何保住 DBA 的工作:)

您可以创建一个非常好的领域模型，将数据持久化到 N 个不同的表中，问题是当您查询该数据时如何将其引入模型并保持 DDD 良好的状态。

谢谢大家，我仍在寻找想法、答案等:)

问候， 佩德罗

您面临的直接问题是如何引入包含一些数据和一些“不相关”数据的数据集，这些数据允许以与域模型一致的方式进一步过滤该数据。

这是一个问题的原因是因为这个概念——引入派生或外围相关数据的多个表与域建模并不真正一致。领域建模是关于定义包含核心应用程序的基本领域知识的关系和复杂的业务逻辑。不产生根本相关对象的多个表意味着它可能不是域模型的一部分。

如果您没有本质上适合您尝试执行的操作的对象，则意味着您的模型不完整，或者在这种情况下，您可能正在尝试将应用程序的用户界面方面泄漏到域模型中。大概是后者。

解决方案还包括用户界面视图架构，如 MVP 或 MVC。域对象是关于跨事务执行业务规则 - 保存和更新。例如，使用 DTO 和 Presenter 来组装任何类型的“新”或“混合”对象，这些对象不代表核心领域知识，而是被构造为以用户想要的某种方式向用户呈现数据。

在这种情况下，您只需创建一个 DTO，将流程和属性 DTO 合并到一个新对象中以供 UI 中使用。

但还有其他一些可能性：

1) 有时您必须问自己是否使用了正确的工具来完成这项工作。我正在开发一个具有非常复杂的领域模型的医疗应用程序。这就是核心应用程序 - 在数据采集过程中执行复杂的规则。但是，一旦获取了这些数据，企业就会有兴趣用它来做许多不同的事情。获取模型和分析模型根本不适合，所以我认为更好的选择是使用 DDD 获取模型，然后使用 ETL 并将数据移动到数据仓库中，而不是尝试让它们一起工作为企业提供一个基于查询而不是 OOP/DDD 构建的独立分析应用程序。

2）领域建模是关于定义反映真实领域的模型，而不是关系数据技术。目标是管理复杂性并创建一个可以随着业务变化而完善和发展的模型。您不会发现很多人做了很多 DDD，甚至假装优化是其中的一个方面。相反，您构建的模型应尽可能与 DDD 一致。如果以后必须这样做，您只需尽可能地妥协该模型，以便将不可接受的性能纳入可接受的范围。

您可以使用查询做很多很多事情，而且效率要高得多。当然，如果有人根本不了解该应用程序，他们可能必须追踪一堆内容，并且很可能必须或多或少地了解整个应用程序，然后才能理解所有内容。 DDD 可以让人们在对应用程序的其余部分基本一无所知的情况下成功地完成某些工作，但在性能或往返方面却没有任何接近最佳的东西。

尽管它似乎试图两全其美，但它既有吸引力又合乎逻辑，我做硬核 SQL 的东西，比如 ETL 和数据仓库，我也做 DDD。我对如何成功地将这两个世界合并到一个应用程序中有些怀疑。您最终得到的应用程序可能没有人可以使用，而且性能也不佳，而不是两全其美。如果你有一堆高效的存储过程，那么里面必然有一堆业务逻辑。如果您还有具有业务逻辑的“对象”，那么您最终得到的是数据库中的业务逻辑、“对象模型”中的业务逻辑，结果只是（又一个）具有类的应用程序，但不是OOP 或 DDD - 与人们多年来一直在做的事情几乎相同，并将其称为“n 层”。

不要误会我的意思 - DDD 应用程序仍然应该构建在可靠的数据库和关系原则上，并且性能没有任何问题。但许多数据库服务器处理实际上是泄漏到数据库的域活动。此外，许多优化数据处理技术都违反了 OOP 和 DDD 的多项原则。

如果您不愿意完全放弃所有数据库内容，并且它对您来说效果很好，那么您可能不需要甚至不想首先转向 DDD 概念。如果您想要 DDD，最​​好的方法是将您拥有的一切视为有价值的领域知识的来源，但就实现细节而言，遗留代码已被完全放弃。 DDD 并不真正适合“移植”非 DDD 应用程序。