在服务中使用多个服务还是多个存储库？ [英] Using multiple services or multiple repositories within service?

问题描述

假设我们有两个实体，EntityA和EntityB。这两个实体都有一个存储库来查询数据库，EntityARepository和EntityBRepository。它们也都有服务，EntityAService和EntityBService。

现在EntityBService中有一个方法，也需要使用EntityA。执行此操作的正确方法是什么？

• EntityBService是否应直接使用EntityARepository？
• EntityBService是否应使用EntityAService？

我可以看出直接使用存储库可能非常方便，但是当不只有两个实体时，它似乎会变得有点混乱。

围绕此主题或建议是否有通用设计模式？

推荐答案

TLDR；视情况而定！

如果您试图遵循领域驱动设计，我认为区分service和repository是个好主意。有不同的定义，在细节上可能会有所不同，但我将坚持使用Martin Fowler的Repository定义：

(.)存储库在域和数据映射层之间充当中介，其作用类似于内存域对象集合。(.)

和service：

服务层从接口客户端层的角度定义应用程序的边界[Cockburn plp]及其可用操作集。它封装应用程序的业务逻辑，在其操作的实现中控制事务并协调响应。

值得一提的是，service不仅仅是repository+业务逻辑。对于大多数简单场景，repository只是结束了对单个数据库的访问，但是对于高级场景，创建单个实体可能需要访问多个数据库，因此repository的角色是从service层中移除此摆动。

以下是您可以想到的：

1. 如果您要做的只是获取EntityA，而没有与EntityA相关的任何业务逻辑，请直接在EntityBService中使用EntityARepository。下面是一个简单的示例：

EntityBService对EntityB执行操作，但纯粹取决于EntityA状态。

2. 如果请求EntityA涉及到与EntityA相关的业务逻辑，请在EntityBService中使用EntityAService。下面是一个简单的示例：

EntityBService对EntityB和EntityA执行操作，如果EntityA不存在则需要创建-创建涉及业务逻辑，如检查是否允许(例如基于用户角色)。

这篇关于在服务中使用多个服务还是多个存储库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！