design-patterns - 使存储库持久性无知的优点/缺点是什么？

Question

通常，存储库应该知道我们决定使用哪个数据库的实现细节。

a) 但是，使存储库持久性无知（即不知道什么持久性介质用于存储数据）的优点/缺点是什么。我能想到的唯一优点是现在可以使用相同的Repository 实现，无论持久化哪种介质数据

b）假设Repository是Persistence Ignorant，那么Repository 接口及其实现都应该驻留在域程序集中？！

谢谢

Answer 1

好吧，使用存储库模式的全部意义在于将域逻辑与持久性逻辑分开，因此，您可以使用具有不同数据存储的相同域实现。因此，存储库的实现必须在某种程度上依赖于数据库的实现似乎很自然。

a) 我认为主要的缺点是性能。存储库越抽象，您将需要设计和实现更多抽象级别，涵盖更多案例。但是，一个专门的存储库会表现得更好，因为它知道其底层存储的全部功能。

另一个缺点是开发和维护成本。我认为这些缺点超过了具有完全通用结构的任何优点......

b) 对于较小的项目，我的回答是“也许”，但对于所有其他项目，我的回答是“不”。它与持久无知没有任何关系。我一直尝试遵循的最佳实践是关注点分离。如果他们试图做不同的事情，那么就把他们分开。它将使您免于以后的许多噩梦。

任何进一步的想法| 想法，我也愿意听他们的:)

Answer 2

您可能希望将存储库接口与实现分离，而不是使存储库“持久化无知”。例如，一个 CustomerRepository 可以由 NHibernateCustomerRepository 和 EFCustomerRepository 实现。这样，实现之间的切换就像更改配置一样容易（至少在幻想世界中）。这有一些现实世界的用途：例如，某些客户坚持使用专有解决方案。

Answer 3

这听起来有点像在想自己。经典的存储库模式旨在将持久性细节从值对象和实体的实现中抽象出来，这是 DDD 中的基本构建块。如果关键是隐藏持久性，那么使存储库持久性不知道会得到什么？

有些人认为他们应该抽象出他们的持久性抽象的细节，例如允许“通用 ORM”而不是“NHibernate”，但在这里我认为这对你自己来说太聪明了。你有一个IRepository，这就足够了。如果你想要一个NHibernateRepository和一个EventStoreRepository，去吧。