在具有服务层的多层架构中，一个服务调用另一个服务是否可以接受？
我有一个多层应用程序，其中包含存储库的数据层。
除此之外，我还有一个服务层。我的理解是每个存储库应该有一个服务。
让 Service A 调用 ServiceB 中的另一个方法可以吗？当然，这会在服务 A 中创建对服务 B 的依赖（我正在使用接口和 DI）。
在我的示例中，我有一个用户服务，用于处理添加用户、验证用户、通过 ID 查找用户等。我还有一个图书服务，它允许我为特定用户添加图书。
图书服务是否应该调用用户服务来检索要添加图书的 User 实例？
I have a multi-tiered app with a data layer containing repositories.
On top of this, I have a service layer. My understanding is that there should be a single service for each repository.
Is it ok to have Service A make a call to another method in ServiceB? This would, of course, create a dependency on Service B in Service A(I am using interfaces and DI).
In my example I have a User service which handles, adding users, authenticating users, finding a user by ID, etc. I also have a Book service which allows me to add book for a specific user.
Should the book service make a call to the user service to retrieve a User instance for which to add books to?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
简短的回答：是的
稍微简短一点：
您的选择是让“图书服务”直接访问“用户存储库”或扩展用户服务，以便它能够添加一本书 - 这都不是一个好的选择......所以执行您所描述的操作是正确的（图书服务访问用户服务）...更“纯粹的选择”是创建一个控制器/聚合/事务/协调器服务，它使用图书服务和用户服务来实现您的目标描述，这样既“直接服务”（书籍和用户）保持“无依赖性”......
Short answer: yes
A bit less short:
Your alternatives are to either let the "book service" directly access the "user repository" or to extend the user service so it is able to add a book - neither a good option... so it is correct to do what you describe (Book Service accesses user service)... a more "pure option" would be to create a controller/aggregate/transaction/coordinator service that uses the book service and the user service to achieve what you describe, this way both "direct services" (book and user) stay "dependency-free"...
是的，这是可以接受的，只要这样做有意义。
如果图书服务需要从用户服务运行逻辑，并且图书服务不调用用户服务，则您必须在图书服务中复制用户服务逻辑。这意味着，如果您的业务逻辑根据服务逻辑的作用发生变化，您必须确保使用该逻辑更新图书服务，否则您将出现错误和不一致（和意外）的行为。
但是，如果您发现这种情况经常发生，您可能必须开始查看每个服务的功能，并可能将它们分解为更小的服务。
Yes this is acceptable, as long as it makes sense to do so.
If the book service requires logic to run from the user service, and the book service does not call on the user service, you will have to duplicate the user service logic in the book service. This means that if your business logic changes for what the service logic does, you have to make sure to update the book service with the logic, or else you will have bugs and inconsistent (and unexpected) behavior.
However, if you find this happening a lot, you might have to start looking at what functionality each service does, and possibly break them apart into smaller services.
用户提到他正在使用 EF。在这种情况下，他可以将用户对象传递给图书服务或用户 ID，并在保存之前在图书存储库中创建用户对象。
User mentioned he was using EF. In this case he can either pass the User Object to the Book Service or the User Id and create a User Object in the Book Repository before the save.