Question

至于我一直在研究存储库模式，＆＃34;存储库＆＃34;应该负责数据持久性和基本查询任务，并且只对此负责。所以在典型的存储库中我看到类似这样的东西：

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

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

可以指出模拟和单元测试功能，但是例如XPO提供了强大的内存持久性功能，非常适合99％的单元测试。

我想我也可以提到EF或NHibernate，它们具有相似的功能。

另一个问题：如果 - 让我们说 - 我不会以这种方式实现存储库模式，我应该在哪里放置更复杂的queriyng（例如基于复杂的标准或用户角色），或者更复杂的项目保存逻辑（使用日志记录，验证等）？

感谢您的帮助。

更新

如何定义通用存储库接口，该接口类型独立地处理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操作：

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

使用Repository模式（例如）DevExpress XPO是否有意义？

1 个答案:

TL; DR

更新