存储库真正应该做什么？

我听说过很多存储库模式，但是我完全不了解存储库应该真正做什么。当我说“存储库应该真正做什么”时，我主要是在担心它应该提供哪些方法。例如，存储库应该真正提供CRUD方法，还是应该提供某种其他方法？

我的意思是，存储库应包含业务逻辑，还是应仅包含与数据存储进行通信并管理要保存或加载的实体的逻辑？

我还听说存储库是聚合的持久性单位。那怎么了 我不明白这在实践中是如何工作的。我认为我们应该只有一个IRepository包含CRUD方法的接口，然后对于任何实体，实现都将仅包含用于保存和从数据存储中检索此类的逻辑。

好吧，您可以在Spring Data Framework中看到一个很好的示例，该示例基于存储库的概念。

在这里，您将看到存储库仅处理数据存储，并且很少包含任何业务逻辑（这是为服务层保留的）。因此，例如，您看一下他们的设计，就会看到他们具有CRUDRepository接口，该接口公开了用于创建，销毁和恢复实体的方法（以及其他方法）。还有一个PagingAndSortingRepository，它添加了额外的功能来精确地进行此操作，排序和分页结果等。

因此，该框架可能是学习良好存储库设计的好地方。

据我所知，Spring Data Framework实现的许多概念都来自一本名为《域驱动设计：软件核心中的复杂性》的出色著作，该书整节专门介绍存储库设计。

您可以考虑获取它的副本。

书中的一小段摘录说明：

REPOSITORY模式是一个简单的概念框架，用于封装这些解决方案并带回我们的模型重点。

存储库将某种类型的所有对象表示为概念集（通常是模拟的）。除了具有更复杂的查询功能外，它的作用类似于集合。添加和删​​除了适当类型的对象，并且REPOSITORY背后的机器将其插入或从数据库中删除。该定义收集了一系列有凝聚力的职责，以提供从早期生命周期到末期访问AGGREGATES根源的权限。

客户端使用查询方法从存储库请求对象，查询方法根据客户端指定的条件（通常是某些属性的值）选择对象。REPOSITORY检索请求的对象，封装数据库查询和元数据映射的机制。资源库可以实现各种查询，这些查询根据客户端要求的条件选择对象。他们还可以返回摘要信息，例如满足某些条件的实例数。他们甚至可以返回汇总计算，例如某个数字属性的所有匹配对象的总计。

一个资源库减轻了客户的负担，客户现在可以与一个简单的意图披露界面进行对话，并询问其在模型方面的需求。为了支持所有这些，需要大量复杂的技术基础架构，但是接口很简单，并且在概念上与域模型相连。

因此：

对于需要全局访问的每种对象类型，创建一个对象，该对象可以提供该类型所有对象的内存中集合的错觉。通过众所周知的全局界面设置访问权限。

提供添加和删除对象的方法，这些方法将封装数据存储中实际插入或删除的数据。提供基于某些条件选择对象并返回完全实例化的对象或属性值符合条件的对象集合的方法，从而封装实际的存储和查询技术。仅为实际需要直接访问的AGGREGATE根提供存储库。让客户专注于模型，委派所有对象存储和对存储库的访问。

它既不应提供直接的CRUD接口，也不应提供业务逻辑。它在业务逻辑和数据库之间进行中介。接口应使用业务逻辑术语，但不能执行业务逻辑本身，更像是业务逻辑原语。例如，您要构建一个电子邮件系统，其中包含用户和消息。您的存储库将为用户和消息提供基本的CRUD操作，但还将提供消息的过滤视图，例如GetUsersNewMessages（user）或GetSearchedMessages（user，searchTerms）。

这个想法是，存储库隐藏了存储的实现方式，并提供了一个干净的界面，可以快速灵活地访问数据。将操作保持在应该发生什么而不是应该如何发生的高层术语上，这意味着您具有更大的灵活性来以最适合基础后备存储的方式来实施它们。