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

Question

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

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

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

谢谢

Answer 1

嗯，使用Repository模式的重点是将域逻辑与持久性逻辑分开，因此，您可以将不同的数据存储使用相同的域实现。因此，存储库的实现必须在某种程度上依赖于数据库实现。

a）我认为主要的缺点是表现。存储库库越抽象，您需要设计和实现更多级别的抽象，涵盖更多案例。但是，知道其底层商店的完整功能后，专用存储库的性能会更好。

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

b）对于较小的项目，我的答案是“可能”，但对于所有其他项目，它是一个坚实的“否”。它与持久无知无关。我总是试图遵循的最佳做法是分离关注点。如果他们试图做不同的事情，那就分开吧。它会在以后噩梦中拯救你。

任何进一步的想法|想法，我也愿意听到它们：）

Answer 2

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

Answer 3

这听起来有点像是在思考自己。经典的存储库模式旨在将持久性细节从DDE的基本构建块 - 值对象和实体的实现中抽象出来。如果重点是隐藏持久性，那么在使存储库持久性不知情的情况下可以获得什么？

有些人认为他们应该抽象出持久性抽象的细节，例如：允许'通用ORM'而不是'NHibernate'，但在这里我认为这对你自己的好处太聪明了。你有一个IRepository，这已经足够了。如果您想要NHibernateRepository和EventStoreRepository，请选择它。