使用Repository模式(例如)DevExpress XPO是否有意义？

Question

就我一直在研究存储库模式而言,"存储库"应该负责数据持久化和基本查询任务,并且仅用于此.所以在典型的存储库中我看到这样的东西:

public interface IProductRepository {
  Product GetByID(int id);
  void Add(Product item);
  void Update(Product item);
  void Delete(Product item);
}

但我想知道如果使用像DevExpress的XPO这样的ORM工具,存储库实现主要由单行方法组成.在XPO旁边仍然创建这个抽象级别是否有意义？

可以指出模拟和单元测试功能,但是例如XPO提供了强大的内存持久性功能,这在99%的时间内非常适合单元测试.

我想我也可以提到EF或NHibernate,它们有类似的功能.

另外一个问题:if - 假设 - 我没有以这种方式实现存储库模式,我应该在哪里放置更复杂的queriyng(例如基于复杂的标准或用户角色),或者更复杂的项目保存逻辑(带有日志记录,验证等)？

谢谢你的帮助.

UPDATE

如何定义一个通用的存储库接口,该接口类型独立地解决了这样的CRUD操作:

public interface IRepository : IDisposable {
  T GetByID<T>(int id);
  IQueryable<T> Query<T>();

  T Create<T>();
  void Update<T>(T item);
  void Delete<T>(T item);
}

然后我可以使用XPO,EF或我选择的任何ORM轻松实现它,即使使用JSON文本文件也是如此.这是一个很好的中间解决方案,还是闻到了？我能看到的唯一缺点是我将把上面提到的那些更复杂的操作放在哪里,但是我可能会在需要时继承这个特殊的接口.

Answer 1

但我想知道如果使用像DevExpress的XPO这样的ORM工具,存储库实现主要由单行方法组成.在XPO旁边仍然创建这个抽象级别是否有意义？

这取决于在持久化和读取域对象时编写特定于技术的无知域.

您可能认为XPO或任何其他OR/M进行了大量的包装和抽象,因此对于存储库模式来说这听起来很愚蠢,因为它是一个不必要的层.

好吧,我会说当你决定使用存储库模式时,最强大的一点就是让你的域名不知道如何将它转化为底层商店理解的内容.OR/M添加了许多细节和依赖关系,如果将它们分散到域代码中,这些细节和依赖关系可能几乎不会改变.

您是否曾意识到存储库模式可能是基于简单配置开关(控制反转)来确定数据持久性的正确工具？我没有考虑这个用于测试目的:选择存储库模式,因为您想要定义域在一个点上与数据进行对话的方式.

您甚至可以使您的代码使用相同OR/M技术的多个版本,因为较新的版本可能不符合旧的要求,但新的域操作仍然能够实例化新的存储库版本,该版本利用了更新的版本优化和能力!

TL; DR

是的,即使您的存储库具有单线方法,它们仍然有用.为未来而战!

更新

如何定义一个通用的存储库接口,该接口类型独立地解决了这样的CRUD操作:

这是完全有效的:它被称为通用存储库.事实上,在我自己的发展中,我总是使用这种模式.