design-patterns - 我应该使用我的 OR/M 作为我的工作单元和存储库吗

Question

我目前将我的工作单元和存储库对象拆分为他们自己的项目，该项目访问包含所有 OR/M (nHibernate) 代码的不同项目。

我听说这只是一个不必要的抽象，我应该使用我的 OR/M 作为存储库和工作单元。

这样做或不这样做的意见和理由是什么？

Answer 1

拆分 OR/M 和Unit of Work and Repository至少有三个优点

• 控制反转和更简单的配置——工作单元和存储库抽象都不应该直接依赖于nHibernate。因此，您将获得解耦代码的优势、遵循 SRP 的明显方式以及其他 SOLID 原则。并且有可能在不需要的地方摆脱nHibernate 。
• 单元测试的执行速度和简单性——单元测试可以模拟/存根工作单元和存储库，而无需在后台运行nHibernate
• 按合同设计——为工作单元和存储库建立单独的合同，而不与nHibernate混合

ps：不要误会我的意思，我认为nHibernate是可用于 .Net 的最佳 OR/M 之一，但通常没有必要在代码中到处都有它。