我在实体框架之上使用服务/存储库层设计模式。一切都很好，直到我想要一个查询来返回关于两个不同实体的数据的合并。
示例是我有两个实体Document和ShoppingBasketItem. 所以我现在有两个服务 aDocumentService和 a ShoppingBasketService。起初，我只是根据用户搜索列出了文档。但后来我想突出显示已经在用户购物篮中的文档。所以文档服务现在需要了解购物篮的概念。
真的，我希望 Document 服务与购物篮无关，明确分离关注点。
所以我的问题是，这是一个好方法吗？或者我是否应该创建一个新服务DocumentBasketService来处理有关文档和购物篮信息的查询？
所以我的问题是，这是一个好方法吗？
这取决于。
我对以这种方式定义服务的方法有一些保留。您希望实现 SoC，这是一件明智的事情，但我认为我们必须努力定义关注点。在这种情况下，关注点真的是领域对象吗？从你面临的问题来看，它看起来不像。
我已经一次又一次地看到这种实现：毕竟，定义一个与 DocumentRepository 一起工作的 DocumentService 似乎是合乎逻辑的。根据我的经验，他们最终会直接将部分/大部分调用转发到存储库并拥有庞大的服务合同，因为最终与 Documents 相关的所有内容都将在 DocumentService 中结束。
如果你在做面向服务，我通常采用的解决方案是让我的服务说“业务”而不是领域，让它们实现业务案例，而不是将它们归类为包装存储库。然后您可以在您的服务中实现 SoC，您的关注点是业务关注点：这些关注点的定义完全取决于您的业务案例，这意味着我无法帮助您。OTOH，如果您真的需要域服务，这条建议完全没用；正如我所说，这取决于您的需求。
因此，普遍有效的观点是：重新考虑您试图分离的问题以及您想要实现的目标。
嗯，我可能想出了一个保持关注点明确分离的答案。
我在文档服务中添加了一个新方法，它接受文档 ID 列表作为参数，这些 ID 是用户购物篮中已经存在的文档。然后服务可以只突出显示文档，例如在文档上设置一个属性以指示它已经在用户的购物篮中。
这样，文档服务就不会查询购物篮，而且对它们一无所知。
因此，总结一下我的控制器操作调用到购物篮服务并获取用户购物篮中已经存在的 id 列表。然后它在传递 id 列表的文档服务上调用获取文档方法。