如果您创建了一个存储库类,它封装了给定实体的所有持久性逻辑,例如 PersonRepository,但您的存储库类没有实现工作单元模式或身份映射模式,它是否仍被视为存储库?换句话说,存储库实现是否需要工作单元和身份映射,或者我们可以将任何封装了我们的持久性逻辑的类称为存储库?
我应该补充一件事。如果存储库不需要这些模式并且它实际上只是持久性方法的容器,那么存储库和 DAO(数据访问对象)之间有什么区别?我们只是为同一个对象创建了多个名称,还是我们缺少存储库应有的部分内容?
如果您创建了一个存储库类,它封装了给定实体的所有持久性逻辑,例如 PersonRepository,但您的存储库类没有实现工作单元模式或身份映射模式,它是否仍被视为存储库?换句话说,存储库实现是否需要工作单元和身份映射,或者我们可以将任何封装了我们的持久性逻辑的类称为存储库?
我应该补充一件事。如果存储库不需要这些模式并且它实际上只是持久性方法的容器,那么存储库和 DAO(数据访问对象)之间有什么区别?我们只是为同一个对象创建了多个名称,还是我们缺少存储库应有的部分内容?
是的,它仍然是一个存储库。
至于如果Repository == DAO,我认为Repository 应该在业务逻辑层,DAO 应该在数据访问层,即我认为它们在不同的层。据我了解,存储库调用 DAO 方法来加载和持久化数据。
我会说存储库和工作单元模式是正交的。
很多时候,我希望单个工作单元跨越多个存储库上的操作,因此它的实现将属于更高层。
基于 Sii 所说的 - 如果存储库和工作单元不相关,对我来说似乎更好。关注点分离?
在考虑关注点分离时,请记住您的存储库将具有数据存储实现方法,允许您将其排除在主代码之外。这对于单元测试以及最终完全替换您的数据存储实现很有帮助(数据存储实现的一个示例是 ASP.NET 中的 LINQ-to-SQL。)