组织服务层中服务之间交互的最佳方法是什么? 例如,我有文档服务和产品服务。在我的情况下,产品可以有自己的文档和管理产品的文档我从产品服务中的文档服务调用适当的方法。所以,我需要在产品服务中创建文档服务实例。我还需要从文档服务中的产品服务中调用一些方法。所以,这些服务中的每一个都指向其他服务,我分别得到stackoverflowexception。 我应该使用哪些设计解决方案来消除这些问题?
答案 0 :(得分:0)
显然,循环依赖是错误的。
您可以使用shared identifiers将Product
和Document
分开。
此外,您可以在应用程序中协调来自外部的服务交互:在ProductService中,您可以LoadProducts(ProductIdentifiers[] identifiers)
返回不可变产品集合,在DocumentService中,您可以返回LoadDocuments(DocumentIdentifiers[] identifiers)
不可变的文件集。
答案 1 :(得分:0)
Application Services应该为外部客户端提供一个API来执行有凝聚力的业务操作。应用程序服务方法通常与您的应用程序的用例匹配。
虽然应用程序服务操作可能需要调用另一个服务(例如,Create Product
用例包括Create Document
用例,也可以单独调用),这不是常态,你应该希望尽可能使您的应用程序服务具有凝聚力。特别是,仅仅因为在您的业务案例中某些时候您开始操纵另一种实体并不意味着您应该将该部分委托给另一个应用程序服务 - 换句话说,每个实体一个应用程序服务不一定是对的。
在任何情况下,从您的域中,它应该清楚地显示2个应用程序服务之间的依赖关系指向哪个方向。在您的示例中,产品服务似乎依赖于文档服务 - 很难想象为什么它会反过来。
如果你真的需要服务A和服务B之间的往返(除非我没有其他选择,否则我不会这样做),你可以尝试将A的实例注入B而不是依赖于DI容器解决了与新实例的依赖关系,解决了堆栈溢出问题 - 如果这就是为什么你首先得到堆栈溢出。