服务与知识库模式与关注点分离

时间:2013-01-03 10:16:56

标签: design-patterns repository-pattern

我在Entity Framework上使用服务/存储库层设计模式。一切都很好,直到我想要一个查询返回有关两个不同实体的数据的合并。

示例是我有两个实体DocumentShoppingBasketItem。所以我现在有两个服务DocumentServiceShoppingBasketService。首先,我刚刚根据用户搜索列出了文档。但后来我想突出显示用户购物篮中已有的文件。因此,文档服务现在需要了解购物篮的概念。

我真的希望Document服务与购物篮无关,明确区分关注点。

所以我的问题是,这是一个好方法吗?或者我应该创建一个新的服务DocumentBasketService来处理有关文件和购物篮信息的查询?

2 个答案:

答案 0 :(得分:3)

  

所以我的问题是,这是一个好方法吗?

取决于。

我有一些保留这种方式定义服务的方法。你想实现SoC,这是一个聪明的事情,但我认为我们必须致力于关注的定义。在这种情况下,关注真的是域对象吗?从你所面临的问题来看,它看起来不像。

我已经看到过这次实现的次数:毕竟,定义使用DocumentRepository的DocumentService似乎是合乎逻辑的。根据我的经验,他们最终直接将部分/大部分调用转发到存储库并签订了巨大的服务合同,因为最终所有与文档有关的内容最终都会在DocumentService中结束。

如果您正在进行面向服务,我通常采用的解决方案是使我的服务说“业务”而不是域,使它们实现业务案例,而不是将它们降级为包装存储库。然后,您可以在您的服务中实现SoC,您的顾虑是业务问题:这些问题的定义完全取决于您的业务案例,这意味着我无法帮助您。 OTOH,如果你真的需要域名服务,这条建议完全没用;正如我所说,这取决于你的需求。

因此,普遍有效的观点是:重新考虑您要分离的问题以及您希望通过该问题实现的目标。

答案 1 :(得分:0)

嗯,我可能已经提出了一个能够明确区分问题的答案。

我在文档服务中添加了一个新方法,该方法接受文档ID列表作为参数,这些ID是用户购物篮中已存在的文档。然后,该服务可以突出显示文档,例如在文档上设置一个属性,表明它已经在用户购物篮中。

这样文档服务就不会查询购物篮,而且对它们一无所知。

所以总结我的控制器动作调用到购物篮服务并获取用户购物篮中已经存在的id列表。然后它调用文件服务上的get documents方法传递id列表。