我的项目中的哪个类应该负责跟踪已经创建了哪些聚合根,以免为同一个实体创建两个实例。我的存储库是否应该保留它创建的所有聚合的列表?如果是,我该怎么做?我是否使用单例存储库(对我来说听起来不对)?另一种选择是将这种“缓存”封装在其他地方是其他类吗?这个类会是什么样子,它适合什么模式?
我没有使用 O/R 映射器,所以如果有一种技术可以处理它,我需要知道它是如何做到的(如它使用的模式)才能使用它
谢谢!
我的项目中的哪个类应该负责跟踪已经创建了哪些聚合根,以免为同一个实体创建两个实例。我的存储库是否应该保留它创建的所有聚合的列表?如果是,我该怎么做?我是否使用单例存储库(对我来说听起来不对)?另一种选择是将这种“缓存”封装在其他地方是其他类吗?这个类会是什么样子,它适合什么模式?
我没有使用 O/R 映射器,所以如果有一种技术可以处理它,我需要知道它是如何做到的(如它使用的模式)才能使用它
谢谢!
我相信您正在考虑Martin Fowler 所描述的身份映射模式。
在他对模式的完整描述中(在他的书中),Fowler 讨论了读/写实体(参与事务的实体)和只读实体(参考数据,理想情况下应该只读一次并随后缓存在内存中)的实现问题.
I suggest obtaining his excellent book, but the excerpt describing this pattern is readable on Google Books (look for "fowler identity map").
Basically, an identity map is an object that stores, for example in a hashtable, the entity objects loaded from the database. The map itself is stored in the context of the current session (request), preferably in a Unit of Work (for read/write entities). For read-only entities, the map need not be tied to the session and may be stored in the context of the process (global state).
我认为缓存是发生在服务级别的事情,而不是在存储库中。存储库应该是“愚蠢的”,只做基本的 CRUD 操作。服务可以足够智能,可以根据需要使用缓存(这可能更像是一种业务规则,而不是低级数据访问规则)。
简单地说,我不让任何代码直接使用存储库——只有服务可以做到这一点。然后其他一切都将相关服务作为接口使用。这为您提供了一个很好的包装器,用于放入 biz 逻辑、缓存等。
我想说,如果这个“缓存”在存储库以外的任何地方管理,那么你就会让问题泄露出去。
存储库是您的项目集合。没有使用存储库的代码必须决定是从存储库还是从其他地方检索对象。
单身听起来像是错误的一生。它可能应该是每个请求。如果您使用的是 IoC/DI 容器,这很容易管理。
似乎您甚至考虑了对同一聚合的多次调用这一事实证明了架构/设计问题。我很想听听一个例子,说明第一次和第二次调用可能是什么,以及为什么它们需要与你的 AR 完全相同的实例。