如何在只调用服务而不调用存储库时保留上下文

本文关键字:调用 存储 上下文 保留 服务 | 更新日期: 2023-09-27 17:57:59

在过去的几天里,我阅读了一些关于存储库模式和工作单元的教程和主题。

我能够理解UoW的想法,这是一个非常好的想法,我现在的问题是如何将这样的东西复制到服务层(这将是我的BLL)。我脑子里有一个想法,我希望我能足够清楚,也许我还没有正确理解这个概念。

让我们想象一下:

  • 我有ClientServiceOrderService

  • 在我的客户端服务中,我有一个名为RemoveClient 的方法

  • 在我的订单服务中,我有一个名为RemoveOrder 的方法

一方面,当我调用我的RemoveClient方法时,我会在允许删除它之前检查大量的东西,在删除的情况下,我也会删除他的所有订单。另一方面,当我调用RemoveOrder时,在删除它之前,我还有其他东西要检查(与RemoveClient方法不同的东西),所有这些删除规则都包含在我的Service层中。

在我最近看到的大多数例子中,服务总是调用存储库的UoW,但由于我的存储库上没有业务逻辑,这对我来说没有意义。当我删除客户端时,总是从ClientService调用OrderService,而不是直接从ClientService调用ClientRepositoryOrderRepository,这不是更好吗,这样可以确保对这两个元素都进行了所有验证。

如果总是调用服务(以保持业务逻辑"流动")更好,我如何将服务保持在相同的上下文中(就像UoW对存储库所做的那样)。

我希望我已经清楚了。非常感谢。

如何在只调用服务而不调用存储库时保留上下文

首先快速阅读这个问题如何正确使用存储库模式?。然后阅读投票最多的答案。现在,有趣的部分在于从这个开始的评论。

长话短说,如果你的业务领域复杂性需要一个丰富的领域模型,那么你应该深入研究DDD的世界,在那里聚合根将简化实体和价值对象之间的交互和关系。这将使存储库的使用更加独特(如果你从CQS的角度来处理持久性,甚至会过时),因为它们的存在将由你的聚合根决定。如果您的域设计满足了所需的所有业务需求,那么您的服务层在业务逻辑负载方面将更加精简,甚至不存在。

最后,拥有一个由DDD规程管理的富域模型可以强制执行级联引用完整性,尤其是当您决定在持久性策略中采用ORM时。