问题标签 [ddd-repositories]

我有一个独特的情况，我正在构建一个基于 DDD 的系统，该系统需要同时访问 Active Directory 和 SQL 数据库作为持久性。最初这不是问题，因为我们的设计是在我们有一个看起来像这样的工作单元的地方设置的：

我们的存储库看起来像这样：

在这个设置中，我们的加载和保存将处理两个数据存储之间的映射，因为我们自己编写了它。工作单元将处理事务并包含存储库将用于持久性的 Linq To SQL 数据上下文。活动目录部分由基础设施中实现的域服务处理，并由每个 Save() 方法中的存储库使用。Save() 负责与数据上下文交互以执行所有数据库操作。

现在我们正在尝试使其适应实体框架并利用 POCO。理想情况下，我们不需要 Save() 方法，因为对象上下文正在跟踪域对象，我们只需要在工作单元上添加 Save() 方法以让对象上下文保存更改，以及一种方法用上下文注册新对象。新提议的设计看起来更像这样：

这解决了实体框架的数据访问问题，但没有解决我们的活动目录集成的问题。以前，它在存储库的 Save() 方法中，但现在它没有家了。工作单元只知道实体框架数据上下文。这个逻辑应该去哪里？我认为这种设计只有在您只有一个使用实体框架的数据存储时才有效。任何想法如何最好地解决这个问题？我应该把这个逻辑放在哪里？

我正在构建一个问卷创建者。问卷由部分组成，部分由页面组成，页面由问题组成。问卷是总根。

部分、页面和问题可以有所谓的短代码，它们在问卷中应该是唯一的（但在数据库中不是唯一的，因此它们不是严格的身份）。我打算使短代码成为一个值对象，并希望在调查问卷中包含它应该是唯一的业务规则，但我不确定如何确保这一点。我的理解是值对象不应该访问存储库或服务层，那么它如何确定它是否是唯一的？

谢谢你的帮助。

达伦

如果您有一个引用客户的订单，该模型是否包含客户的 ID 或客户对象的副本，如值对象（考虑 DDD）？

我想这样做：

现在我这样做：

在传递给表单的视图模型中包含完整的客户对象而不是 ID 会更方便。否则，我需要弄清楚如何将供应商信息获取到订单按 ID 引用的视图。

这也意味着存储库了解如何处理它在调用 save 时在 order 对象中找到的客户对象（如果我们选择第一个选项）。如果我们选择第二个选项，我们需要知道在视图模型中放置它的位置。

可以肯定的是，他们会选择现有客户。但是，也可以肯定他们可能希望在显示表单上就地更改信息。有人可能会争辩说让控制器提取客户对象，将客户更改单独提交到存储库，然后将更改提交到订单，将客户 ID 保留在订单中。

我正在寻找有关以下 DDD 概念的书籍或博客文章，这些概念特定于 MVC 和 C# 代码。快速总结：来自特殊存储库方法的部分填充域模型，并且仅将更改的域模型属性作为 JSON 从客户端发送回。

更多细节：

• 如果您有一个客户对象但需要一个只有客户编号和客户名称的下拉列表，您将创建一个特殊的存储库方法来返回客户的完整 IList，但只填充客户 ID 和客户名称，其他属性为空或空的。这节省了为视图模型创建大量特殊类的时间。

• 如果您正在编辑客户，您将在服务器的会话变量中缓存客户对象，然后 JSON 序列化包含客户 DDL 和客户端的第一个客户对象的视图模型，可能将 JSON 嵌入来自服务器。让 JSON 解析为 MVC 控制器方法“对象参数”（将发布数据从 JSON 重新组装为对象参数）会非常好。

• 客户端 (JavaScript) 实例化客户对象并将对象属性绑定到相应的同名 HTML 输入语句。当一个改变时，另一个改变。还为 IList 对象添加一个模板概念。当输入值更改（事件）时，它还会将客户对象属性标记为脏。

• 提交后，仅将更改的（脏）对象属性序列化为 JSON 并发送回服务器。未更改的属性被简单地排除在外。服务器会将缓存的客户对象与部分 JSON 客户对象（仅限更改）组合，将生成的客户对象提交到存储库以进行持久化。

这是一个非常棒的概念。我想阅读有关理论并获得待办事项清单。

我注意到存储库通常以以下任一方式实现：

方法一

方法二

方法 1 具有集合语义（这是定义存储库的方式）。我们可以从存储库中获取一个对象并对其进行修改。但我们不会告诉集合更新它。以这种方式实现存储库需要另一种机制来持久化对内存对象所做的更改。据我所知，这是使用工作单元完成的。但是，有些人认为只有当您需要系统中的事务控制时才需要 UoW。

方法 2 消除了拥有 UoW 的需要。您可以调用 Save() 方法，它会确定对象是新对象并且应该被插入还是被修改并且应该被更新。然后它使用数据映射器将更改持久保存到数据库中。虽然这使生活变得更加轻松，但建模的存储库没有集合语义。该模型具有 DAO 语义。

我真的很困惑。如果存储库模拟内存中的对象集合，那么我们应该根据方法 1 对它们进行建模。

您对此有何看法？

莫什

域模型和存储库可以在单独的 dll 中吗？

在 3 层架构中，我想我会将领域模型放在业务层中，将存储库放在数据访问层中。

我感到困惑，因为我的理解是域模型使用存储库，而存储库应该从域模型返回对象，这会导致循环依赖。

我一定是误解了上述一个或多个概念。

任何澄清将不胜感激，因为这一直困扰我一段时间，谢谢。

VS 2010 / C#

尝试组织解决方案并寻找用于命名将托管存储库接口的项目的选项。

我有：MyProject.Domain

我的项目.WebUI

MyProject.Repositories

MyProject.Interfaces??

到目前为止，“接口”是我想出的最好的名字，但我不喜欢它。有什么想法/建议吗？

存储库类应该进入哪一层？域还是基础设施？

鉴于：

• 你有一个包含表示层、业务层和数据层的架构。
• 您正在应用领域驱动设计。
• 您正在使用一个对象关系映射器，它可以让您创建面向对象的查询（例如，NHibernate，它可以让您创建 HQL 查询）。

问题：

您应该将面向对象的查询放在哪一层？

我的想法：

我认为将它们放入表示层通常是没有意义的。但我不知道是否将它们放入业务层或数据层。

示例（NHibernate）：

假设您的业务逻辑需要一些方法 GetCustomersPossiblyInterestedIn(Product p)。然后，您可以创建一个复杂的 HQL 查询，该查询选择客户已经购买了与 p 属于同一类别的产品的客户对象。

论点 a)

一方面，我会说这个查询显然是业务逻辑，因为根据客户是否购买了同一类别的产品而将其视为可能对产品感兴趣的决定是一个业务决策。您不妨选择在同一类别中以相似价格购买过多个产品的客户，例如

论点 b)

另一方面，业务层不应该依赖于数据层，所以直接在业务层使用NHibernate敲响了警钟。

可能的解决方案 1)

创建您自己在业务层中使用的面向对象的查询语言，并在数据层中转换为 HQL。我认为这会导致很多开销。如果您使用基于查询对象的查询语言而不是解析的查询语言，您可能会付出一些努力，但我的反对意见仍然适用。

可能的解决方案2）

在业务层直接使用NHibernate 是可以的，因为NHibernate 能够提供HQL、ISession 等的抽象级别适合业务层。没有必要包装它。

你怎么看？

编辑：

有关密切相关的讨论，请参阅Ayende Rahien 的“Repository is the new Singleton”和“在 DAL 中封装数据访问的错误神话” 。

我试图让 EF4 与 ncommon 1.1 一起工作，它提供了 DDD 模式，例如 UnitOfWork、规范、存储库。

NCommon 配置行抛出以下异常：

发生 SynchronizationLockException

对象同步方法是从未同步的代码块中调用的。

引发错误的实际代码是：

这是我正在运行的代码。