聚合、存储库和服务层
选一门与其他几个课程有关系的课程。第一类可以看作是聚合（根）。从服务层的角度来看，如何最好地拆分呼叫？
- 调用整个对象图的聚合存储库，并从该特定存储库调用其他存储库来处理关系的保存（每种类类型一个存储库。
- 调用整个对象图的聚合存储库并处理该存储库中的所有内容）一种方法（因此在同一方法中保存所有关系），
- 从服务层调用聚合的存储库，然后直接从服务层调用相关类的存储库
- 添加一个额外的 。服务和存储库之间的层以及该额外层中的层与选项 3 类似。
我已经在生产代码中看到了所有 3 种可能的解决方案，但我对最干净的解决方案以及为什么选择的原因感兴趣对于这种方法。
Take a class which has relations with a couple of other classes. The first class can be seen as the aggregate(root). Seen from the point of the service layer how would one best split the calls?
- Call the repository of the aggregate for the entire object graph and call from that particular repository other repositories to handle the saving of the relations (one repository per type of class.
- Call the repository of the aggregate for the entire object graph and handle all in that one method (so saving of all the relations in that same method).
- From within the service layer, call the repositories for the aggregate and then directly after that, again from the service layer, call the repositories of the related classes.
- Add an extra layer in between the service and the repositories and from within that extra layer do like in option 3.
I've seen already all 3 possible solutions in production code but I'm interested in the cleanest solution and a reason as to why one would opt for that approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对我来说，这将是选项 1 和 2 之间的选择（我喜欢保持“上层服务层”尽可能简单）。
我会选择哪一个在一定程度上取决于聚合的各个类型的使用方式；如果它们总是（至少目前）作为这个聚合的一部分而不是独立使用，我可能会让聚合存储库也处理它们（但可能仍然在单独的方法中），但如果各个部分也可以独立使用（或作为其他聚合的一部分），我可能会倾向于为它们提供单独的存储库对象，并从聚合存储库调用这些存储库。
For me it would be a choice between option 1 and 2 (I like to keep the "upper service layer" as simple as possible).
Which one of those I would choose would depend a bit on how the individual types of the aggregate are used; if they are always (at least currently) used as part of this one aggregate and not stand-alone, I would probably let the aggregate repository deal with them as well (but perhaps still in separate methods), but if the individual parts can also be used stand-alone (or as parts of other aggregates) I would probably lean towards having separate repository objects for them, and call into those repositories from the aggregate repository.