在具有服务层的多层架构中，让一个服务调用另一个服务是否可以接受？答案

【问题标题】：In multi-tier architecture with a service layer, is it acceptable to have one service call another service?在具有服务层的多层架构中，让一个服务调用另一个服务是否可以接受？
【发布时间】：2011-10-26 18:47:40
【问题描述】：

我有一个包含存储库的数据层的多层应用程序。

除此之外，我还有一个服务层。我的理解是每个存储库都应该有一个服务。

可以让服务 A 调用服务 B 中的另一个方法吗？当然，这会在服务 A 中创建对服务 B 的依赖（我正在使用接口和 DI）。

在我的示例中，我有一个用户服务，它处理、添加用户、验证用户、按 ID 查找用户等。我还有一个图书服务，它允许我为特定用户添加图书。

图书服务是否应该调用用户服务来检索要为其添加图书的用户实例？

【问题讨论】：

是的，可以接受。您是否愿意让预订服务使用用户存储库？

标签： c# asp.net .net entity-framework multi-tier

【解决方案1】：

简短回答：是的

短一点：

您的替代方案是让“图书服务”直接访问“用户存储库”或扩展用户服务以便它能够添加一本书 - 这不是一个好的选择......所以做什么是正确的您描述的（图书服务访问用户服务）......一个更“纯粹的选择”是创建一个控制器/聚合/事务/协调器服务，该服务使用图书服务和用户服务来实现您所描述的，这样既“直接服务”（书籍和用户）保持“无依赖”......

【讨论】：

您对如何避免循环依赖有什么建议吗？随着应用程序的增长，让用户服务引用图书服务可能会很方便。 “纯选项”是否避免了这种情况？如果是这样，你能帮我理解怎么做吗？似乎可能需要一个额外的逻辑层。也许这就是你上面的建议？但如果它只是另一个“服务”，那么将来可能很容易无意中添加循环依赖。
“纯选项”避免了这种情况……您可以将其视为服务之上的服务，更像是“面向用例的服务/外观”。它使任何消费者免受细节的影响，并避免在书籍和用户服务之间引入依赖关系。它使 2 个服务之间的关系变得明确，并将其本地化到特定的用例。

【解决方案2】：

是的，这是可以接受的，只要这样做有意义。

如果图书服务需要从用户服务运行逻辑，而图书服务不调用用户服务，则您必须在图书服务中复制用户服务逻辑。这意味着如果您的业务逻辑针对服务逻辑所做的更改，您必须确保使用该逻辑更新图书服务，否则您将出现错误和不一致（和意外）的行为。

但是，如果您发现这种情况经常发生，您可能必须开始查看每个服务的功能，并可能将它们分解为更小的服务。

【讨论】：

【解决方案3】：

用户提到他正在使用 EF。在这种情况下，他可以将用户对象传递给图书服务或用户 ID，并在保存之前在图书存储库中创建一个用户对象。

【讨论】：

你会把这个方法放在哪里？
这是我的意图，但我将如何处理用户 ID？由于我使用的是 EF，我需要一个用户对象来将 Book 与...相关联……这意味着我必须在某个时候调用用户存储库我应该直接从图书服务调用用户存储库吗？这对我来说似乎不是一个明显的选择。
哦，你没有提到你在使用 EF。在这种情况下，您可以将用户对象传递给图书服务，或者您仍然可以传递用户 ID 并在图书存储库中创建用户对象以进行保存。