带或不带 DAL 包装器的 ORM答案

【问题标题】：ORM with or without DAL wrapper带或不带 DAL 包装器的 ORM
【发布时间】：2011-04-14 18:52:21
【问题描述】：

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

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

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

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

我一直在考虑将 ORM（尚未对 ORM 本身做出决定）包装在一个通用 ORM 容器中，并将其传递给每个域对象的查找器类。但是，我完全不确定通用 ORM 包装器类会是什么样子！

有没有人在这里得到任何现实生活的建议？请不要觉得有必要给你的答案涂上糖衣！！

【问题讨论】：

标签： orm layer

【解决方案1】：

为了在这些问题上指出比我更聪明的人的方向，Ayende 在他的博客文章The false myth of encapsulating data access in the DAL 中强调的通用 ORM 包装器的问题之一是不同的 ORM 本质上差异太大而无法封装有效地，具有不同的事务处理方法等。

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

【讨论】：

我在这里。将数据访问抽象为一个整体（或根本不抽象）似乎是普遍的想法。这可能是我很难想象一个像样的包装的原因！

【解决方案2】：

存储库有许多功能：

它允许使用模拟实现进行单元测试
它允许您向消费者隐藏 ORM 的完整实现，并实现安全功能
它为业务逻辑提供了一个抽象层（尽管有些人为此使用了单独的服务层），并且
它允许您在必要时更改 ORM 实现。

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

【讨论】：

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