c# - 将存储库模式与(例如)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，它们具有相似的功能。

另一个问题:如果 - 让我们说 - 我不以这种方式实现存储库模式，我应该在哪里放置更复杂的查询(例如基于复杂的条件或用户角色)或更复杂的项目保存逻辑(与日志记录、验证等)？

感谢您的帮助。

更新

如何定义一个通用的存储库接口(interface)，它可以像这样独立地处理 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 文本文件。这是一个很好的中间解决方案，还是有味道？我能看到的唯一缺点是我应该把上面提到的那些更复杂的操作放在哪里，但可能我可以在需要时从中继承特殊接口(interface)。

Answer 1

But I wonder what if one uses an ORM tool like DevExpress' XPO, a repository implementation would mostly consist of one-liner methods. Does it make sense to still create this abstraction level beside XPO?

在持久化和读取您的域对象时，它取决于编写特定于技术的无知域。

您可能认为 XPO 或任何其他 OR/M 做了很多包装和抽象，所以存储库模式听起来很愚蠢，因为它是一个不必要的层。

好吧，我想说的是，当您决定使用 存储库模式 时，最重要的一点就是让您的域变得不可知，不知道它是如何转化为底层商店所理解的内容的。 OR/M 添加了很多细节和依赖项，如果您将它们分布在您的域代码中，这些细节和依赖项可能几乎不会改变。

您是否意识到存储库模式可能是根据简单的配置开关(控制反转)来决定什么持久化您的数据的正确工具？我不考虑这个用于测试目的:选择存储库模式，因为你想定义你的域如何在一个点上与数据对话。

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

长话短说

是的，即使您的存储库具有单行方法，它们仍然有用。为 future 而战!

更新

What about defining a generic repository interface which type-independently addresses CRUD operetaions like this:

这是完全正确的:它被称为通用存储库。事实上，在我自己的开发中，我一直在使用这种模式。