洋葱架构 - 库VS服务？ [英] Onion Architecture - Repository Vs Service?

问题描述

我学习从巴勒莫杰弗里著名的洋葱架构。
不特定于这种模式，但我不能清楚地看到仓库和域服务之间的分离。
我（MIS）了解到，库关注数据访问和服务更多的是关于业务层（参考一个或多个库）。

I am learning the well-known Onion Architecture from Jeffrey Palermo. Not specific to this pattern, but I cannot see clearly the separation between repositories and domain services. I (mis)understand that repository concerns data access and service are more about business layer (reference one or more repositories).

在许多例子，一个仓库，似乎有某种商业逻辑背后像 GetAllProductsByCategoryId 或 GetAllXXXBySomeCriteriaYYY 。

In many examples, a repository seems to have some kind of business logic behind like GetAllProductsByCategoryId or GetAllXXXBySomeCriteriaYYY.

有关名单，似乎服务只是一个没有任何逻辑上的库包装。
对于层次结构（父母/儿童/子女），这几乎是同样的问题：它是资源库加载完整的层次结构中的作用

For lists, it seems that service is just a wrapper on repository without any logic. For hierarchies (parent/children/children), it is almost the same problem : is it the role of repository to load the complete hierarchy ?

推荐答案

信息库的不是来访问数据库网关。这是一个抽象，允许你存储和加载域某种形式的持久性存储的对象。 （数据库，缓存甚至普通的集合）。它采取或返回域对象，而不是其内部磁场，因此它是一个面向对象的接口。

The repository is not a gateway to access Database. It is an abstraction that allow you to store and load domain objects from some form of persistence store. (Database, Cache or even plain Collection). It take or return the domain objects instead of its internal field, hence it is an object oriented interface.

这是不建议添加像 GetAllProductsByCategoryId 或 GetProductByName 来存储库中，因为您将添加更多的一些方法多方式信息库为您的使用情况/对象字段计数增加。相反，最好是有这需要一个规范的存储库的查询方法。您可以通过规范检索的产品不同的实现。

It is not recommended to add some methods like GetAllProductsByCategoryId or GetProductByName to the repository, because you will add more and more methods the repository as your use case/ object field count increase. Instead it is better to have a query method on the repository which takes a Specification. You can pass different implementations of the Specification to retrieve the products.

总体上，信息库模式的目标是创造一种不需要时用例的变化而变化的存储抽象。 本文有关领域建模Repository模式会谈很详细。您可能会感兴趣。

Overall, the goal of repository pattern is to create a storage abstraction that does not require changes when the use cases changes. This article talks about the Repository pattern in domain modelling in great detail. You may be interested.

对于第二个问题：如果我在code看到 ProductRepository ，我期望它返回我的产品清单。我也希望每一个产品的实例就完成了。例如，如果产品有产品详情对象的引用，我想到的是 Product.getDetail（）返回我一个产品详情实例，而不是空。也许库负荷的实施产品详情与产品一起，也许是 getDetail（）方法调用 ProductDetailRepository 的飞行。我真的不关心作为仓库的用户。这也有可能是产品只返回时，我称之为产品详情 ID getDetail（）。它是从视图存储库的合同点完美的罚款。然而，它的复杂性我的客户code和力量我打电话 ProductDetailRepository 自己。

For the second question: If I see a ProductRepository in the code, I'd expect that it returns me a list of Product. I also expect that each of the Product instance is complete. For example, if Product has a reference to ProductDetail object, I'd expect that Product.getDetail() returns me a ProductDetail instance rather than null. Maybe the implementation of the repository load ProductDetail together with Product, maybe the getDetail() method invoke ProductDetailRepository on the fly. I don't really care as a user of the repository. It is also possible that the Product only returns a ProductDetail id when I call getDetail(). It is perfect fine from the repository's contract point of view. However it complicates my client code and forces me to call ProductDetailRepository myself.

顺便说一句，我见过，是专为包装在我过去的资源库类的许多服务类。我认为这是一个反模式。最好是有服务的调用者直接使用存储库。

By the way, I've seen many service classes that solely wrap the repository classes in my past. I think it is an anti-pattern. It is better to have the callers of the services to use the repositories directly.

这篇关于洋葱架构 - 库VS服务？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！