asp.net-mvc – 洋葱建筑 – 存储库与服务?

前端之家收集整理的这篇文章主要介绍了asp.net-mvc – 洋葱建筑 – 存储库与服务?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在从杰弗里·巴勒莫学习着名的洋葱建筑。
不是特定于这种模式,但是我看不清楚存储库和域服务之间的分隔。
我(误)了解存储库涉及数据访问和服务更多关于业务层(参考一个或多个存储库)。

在许多例子中,存储库似乎具有像GetAllProductsByCategoryId或GetAllXXXBySomeCriteriaYYY这样的业务逻辑。

对于列表,似乎服务只是存储库中的包装器,没有任何逻辑。
对于层次结构(父/子/子),几乎是同样的问题:存储库的作用是加载完整的层次结构?

解决方法

存储库不是访问数据库的网关。这是一种抽象,允许您从某种形式的持久性存储中存储和加载域对象。 (数据库,缓存或甚至纯粹的集合)。它采取或返回域对象而不是其内部字段,因此它是面向对象的接口。

不建议将诸如GetAllProductsByCategoryId或GetProductByName之类的方法添加到存储库中,因为随着用例/对象字段计数的增加,您将添加越来越多的存储库方法。相反,最好在存储库中具有一个“规范”的查询方法。您可以通过规范的不同实现来检索产品。

总的来说,存储库模式的目标是创建一个存储抽象,当用例更改时不需要更改。 This article详细介绍了域建模中的Repository模式。你可能有兴趣

对于第二个问题:如果我在代码中看到一个ProductRepository,我希望它返回一个Product列表。我也期望每个Product实例都是完整的。例如,如果Product有对ProductDetail对象的引用,那么我希望Product.getDetail()返回一个ProductDetail实例而不是null。可能实施的库将ProductDetail与Product一起加载,也许getDetail()方法即时调用ProductDetailRepository。我并不关心作为存储库的用户。当我调用getDetail()时,产品也可能只返回ProductDetail id。从仓库合同的角度来看,这是完美的。然而,我的客户端代码复杂化,迫使我自己调用ProductDetailRepository。

顺便说一句,我看到过许多服务类,只包含过去的存储库类。我认为这是一种反模式。最好让服务的呼叫者直接使用存储库。

猜你在找的asp.Net相关文章