带或不带DAL包装的ORM

在我所看到的所有示例中，ORM都倾向于直接使用或在某种DAL存储库后面使用（大概是为了将来可以交换它们）

我不喜欢直接使用ORM，因为它很难替换，但我同样不喜欢失去它提供的完整域更改跟踪

在过去，我会为我的领域中的每个对象编写一个数据映射器类（Fowler），但我从经验中了解到，这种CRUD编码消耗了我大约1/3的时间

我意识到改变我的数据访问策略是不太可能的（我以前从来没有这样做过），但我真的担心，通过直接使用ORM，我会将自己锁定在使用它直到时间结束

我一直在考虑将ORM（还没有关于ORM本身的决定）包装在一个通用ORM容器中，并将其传递给每个域对象的查找器类。然而，我完全不确定通用ORM包装类会是什么样子

---

这里有人有什么现实生活中的建议吗？请不要觉得有必要在你的答案上加糖

存储库有许多功能：

它允许使用模拟实现进行单元测试

它允许您向使用者隐藏ORM的完整实现，并实现安全功能

它为业务逻辑提供了一个抽象层（尽管有些人为此使用单独的服务层），并且

它允许您在必要时更改ORM实现

---

另一个通用化ORM的容器对我来说太过工程化了。正如您所指出的，您不太可能更改底层实现，但如果您这样做，您的存储库似乎是一个明智的选择。

在这些问题上为您指明一个比我聪明得多的人的方向，正如Ayende在他的博客文章中强调的那样，拥有通用ORM包装器的问题之一是不同的ORM本质上太不同，无法有效地进行封装，具有不同的事务处理方法，等等

---

最重要的是，无论如何，切换ORM并没有多大意义——在发生变化的情况下封装DAL的主要原因之一是为了应对数据库切换，但大多数现代ORM无论如何都能够处理许多不同的数据库。

谢谢。存储库解决方案的问题是，我希望域中的每个对象都有一个存储库。同时，ORM工具跟踪整个领域的变化。我应该在存储库之间共享单个ORM上下文（以便能够执行单个“提交”），还是应该为每个存储库提供单独的ORM上下文？如果我做了后者（我已经习惯了），那么我将可能不得不在事务之间架起桥梁（而不是单个事务），并失去一个ORM的主要好处。您将在每个存储库中以“工作单元”为基础实例化ORM上下文。这为您提供了所需的事务功能，而无需考虑“全局、通用”对象。我正在考虑使用ORM上下文作为跨多个存储库的工作单元的唯一代表。。。我不明白如何通过为每个存储库实例化一个新的ORM上下文来获得一个事务（按事务，我特别指的是数据库事务）？感谢到目前为止的帮助。在大多数ORM的IME中，ORM上下文是一个相当轻量级的对象，所以将其保留足够长的时间以包含单个事务，但不能超过这个时间。这有意义吗？我不认为域中的每个对象都需要存储库。你为什么要那样做？它只是给已经存在的对象添加了另一个不必要的抽象层。让您的存储库成为您完成事务的地方，并在每个事务的基础上使用您在ORM中需要的任何对象来实现这一点。是的，太棒了。谢谢你的帮助！我现在对自己的选择更有信心了。我在这里等你。将数据访问抽象为一个整体（或者根本不抽象）似乎是一般的想法。这可能就是为什么我很难想象一个像样的包装！