DDD 中的数据访问？

发布于 2024-07-05 12:45:09 字数 274 浏览 14 评论 0原文

阅读 Evan 和 Nilsson 的书后，我仍然不确定如何在域驱动项目中管理数据访问。 CRUD 方法应该是存储库的一部分，即 OrderRepository.GetOrdersByCustomer(customer)，还是应该是实体的一部分：Customer.GetOrders()。后一种方法看起来更面向对象，但它将在多个对象之间分配单个实体类型的数据访问，即 Customer.GetOrders()、Invoice.GetOrders()、ShipmentBatch.GetOrders() 等。插入和更新怎么样？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

日裸衫吸 2024-07-12 12:45:09

我已经完成了你所说的两种方法，我现在首选的方法是持久无知（或 PONO - 普通 Ole'.Net 对象）方法，其中你的域类只担心是域类。他们不知道它们是如何被持久化的，甚至不知道它们是否被持久化。当然，有时你必须务实一点，并允许诸如 Id 之类的东西（但即使这样，我也只是使用具有 Id 的图层超级类型，这样我就可以有一个点，其中像默认值这样的东西存在

）这样做的原因是我努力遵循单一职责原则。通过遵循这个原则，我发现我的代码更易于测试和维护。当需要时进行更改也更容易，因为我只需考虑一件事。

需要注意的一件事是存储库可能遭受的方法膨胀。 GetOrderbyCustomer.. GetAllOrders.. GetOrders30DaysOld.. 等等。解决此问题的一个好方法是查看查询对象模式。然后您的存储库只需接受一个查询对象即可执行。

我还强烈建议研究 NHibernate 之类的东西。它包含许多使存储库如此有用的概念（身份映射、缓存、查询对象......）

回复收藏 0 原文

谜泪 2024-07-12 12:45:09

CRUD-ish 方法应该是存储库的一部分...ish。但我认为你应该问为什么你有一堆 CRUD 方法。他们真正做什么？它们的真正用途是什么？如果您实际上指出了应用程序使用的数据访问模式，我认为这会使存储库变得更加有用，并且当您的域发生某些类型的更改时，您不必进行鸟枪手术。

CustomerRepo.GetThoseWhoHaventPaidTheirBill()

// or

GetCustomer(new HaventPaidBillSpecification())

// is better than

foreach (var customer in GetCustomer()) {
    /* logic leaking all over the floor */
}

“保存”类型的方法也应该是存储库的一部分。

如果您有聚合根，这可以防止存储库爆炸或逻辑分散：您没有 4 x # 的实体数据访问模式，只有您在聚合根上实际使用的模式。

那是我的 0.02 美元。

CRUD-ish methods should be part of the Repository...ish. But I think you should ask why you have a bunch of CRUD methods. What do they really do? What are they really for? If you actually call out the data access patterns your application uses I think it makes the repository a lot more useful and keeps you from having to do shotgun surgery when certain types of changes happen to your domain.

CustomerRepo.GetThoseWhoHaventPaidTheirBill()

// or

GetCustomer(new HaventPaidBillSpecification())

// is better than

foreach (var customer in GetCustomer()) {
    /* logic leaking all over the floor */
}

"Save" type methods should also be part of the repository.

If you have aggregate roots, this keeps you from having a Repository explosion, or having logic spread out all over: You don't have 4 x # of entities data access patterns, just the ones you actually use on the aggregate roots.

That's my $.02.

回复收藏 0 原文

心凉 2024-07-12 12:45:09

DDD 通常更喜欢存储库模式而不是您使用 Customer.Save 暗示的活动记录模式。

Active Record 模型的一个缺点是它几乎假定一个单一的持久性模型，除非有一些特别侵入性的代码（在大多数语言中）。

存储库接口是在领域层定义的，但不知道你的数据是否存储在数据库中。例如，使用存储库模式，我可以创建一个 InMemoryRepository，以便可以单独测试域逻辑，并在应用程序中使用依赖项注入来让服务层实例化 SqlRepository。

对于许多人来说，拥有一个仅用于测试的特殊存储库听起来很愚蠢，但如果您使用存储库模型，您可能会发现您的特定应用程序实际上并不需要数据库；您可以使用存储库模型。有时一个简单的 FileRepository 就可以解决问题。在您知道自己需要数据库之前就将自己与数据库结合起来可能会受到限制。即使数据库是必要的，针对 InMemoryRepository 运行测试也会快得多。

如果您没有太多领域逻辑方面的知识，那么您可能不需要 DDD。 ActiveRecord 非常适合解决很多问题，特别是当您主要有数据和少量逻辑时。

回复收藏 0 原文

小鸟爱天空丶 2024-07-12 12:45:09

让我们退后一步。埃文斯建议存储库返回聚合根而不仅仅是实体。因此，假设您的客户是包含订单的聚合根，那么当您从其存储库中获取客户时，订单也会随之而来。您可以通过导航从“客户”到“订单”的关系来访问订单。

customer.Orders;

因此，为了回答您的问题，CRUD 操作存在于聚合根存储库上。

CustomerRepository.Add(customer);
CustomerRepository.Get(customerID);
CustomerRepository.Save(customer);
CustomerRepository.Delete(customer);

Let's step back for a second. Evans recommends that repositories return aggregate roots and not just entities. So assuming that your Customer is an aggregate root that includes Orders, then when you fetched the customer from its repository, the orders came along with it. You would access the orders by navigating the relationship from Customer to Orders.

customer.Orders;

So to answer your question, CRUD operations are present on aggregate root repositories.

CustomerRepository.Add(customer);
CustomerRepository.Get(customerID);
CustomerRepository.Save(customer);
CustomerRepository.Delete(customer);

回复收藏 0 原文

清眉祭 2024-07-12 12:45:09

即使在 DDD 中，我也会将数据访问类和例程与实体分开。

原因是，

可测试性提高了
关注点分离和模块化设计
从长远来看更易于维护，当您添加实体、例程时，

我不是专家，只是我的意见。

回复收藏 0 原文

安稳善良 2024-07-12 12:45:09

Nilsson 的应用 DDD&P 的烦人之处在于，他总是以“我不会在现实世界的应用程序中这样做，但是......”开始，然后他的例子如下。回到主题：我认为 OrderRepository.GetOrdersByCustomer(customer) 是可行的方法，但 ALT.Net 邮件列表上也有讨论 (http://tech.groups.yahoo.com/group/altdotnet/）有关 DDD。

回复收藏 0 原文

~没有更多了~