为什么要抽象一个 ORM？答案

【问题标题】：Why abstract an ORM?为什么要抽象一个 ORM？
【发布时间】：2013-06-10 16:20:44
【问题描述】：

我经常看到使用存储库模式来抽象 ORM 的代码。为什么这样做？ ORM 不是已经是一个抽象并且本身就充当了一个存储库吗？

有没有很大的区别

public class EmployeeRepo 
{
    GetById(int id) { //Access ORM here };
}

消费数据：

public class MyController{
    private EmployeeRepo = _Repo = new EmployeeRepo();

    public ActionResult ShowEmployee(int id)
    {
        var emp = _Repo.GetById(id);
        //Versus
        var emp = ORM.Where(e => e.Id == id);

        return View(emp);
    }
}

我为什么要重新创建 ORM 已经提供给我的东西？

【问题讨论】：

如果你有一个“通用”存储库层，你就独立于你正在使用的实际 ORM/数据库。它还用作可以独立于实际数据库进行测试的层。但它需要更多的工作 - 显然 - 所以它在小型应用程序中可能没有意义。但在企业开发环境中，有数十名开发人员在开发应用程序，拥有一个不需要任何知识或经验的存储库层就容易得多。
@marc_s 如果您使用存储库来抽象您正在使用的数据库和实现，我可以理解，但是 ORM 已经这样做了，因此开发人员不必知道任何特定于数据库的信息，除非某些情况。我认为从事项目的开发人员应该对正在使用的技术有很好的了解，否则他们最终可能会错误地使用它，就像任何框架一样，都有最佳实践。

标签： c# orm repository abstraction

【解决方案1】：

我经常看到代码使用存储库模式来抽象 ORM。

这在 99.(9)% 的项目中是不需要的。程序员似乎欣喜若狂，因为他们可以创建另一个抽象而不是抽象。

我为什么要重新创建 ORM 已经提供给我的东西？

你不应该这样做，事实上，你会制造更多的问题，仅举几例：

客户是否明确要求该功能可以在 ORM 之间轻松切换？真的吗？你有这方面的预算吗？
您已准备好为您的抽象引入测试覆盖率，您有时间和金钱来做这件事
您有日志框架吗？
您是否考虑过设计时间来找出您可以支持的通用 API？缓存、分片、负载分配、存储过程、触发器呢？
您准备好花时间为多个 ORM 升级到新版本，准备好修复重大更改了吗？

更好的是使用 ORM 本身的接口/基类，因此您可以轻松地对其进行测试和模拟。

【讨论】：

【解决方案2】：

我知道这是一个老问题，但这个话题很有趣。

我同意直接使用 ORM 更容易，并且可能是在简单项目中做正确的事情。

但是，如果您正在开发长期存在的复杂系统，那么在您的业务逻辑中直接依赖 ORM 意味着您在数千个地方都依赖该 ORM。由于该 ORM 中的重大更改或仅仅因为您决定以其他方式做某事，这将不可避免地在未来产生问题。

因此，抽象 ORM 与其说是轻松切换 ORM 的能力，不如说是关于将您的项目与外部依赖解耦（由于其复杂性和持续开发，流行的 ORM 中发生重大变化的可能性足够高）。此外，拥有这样一个解耦架构，您将获得项目的良好可测试性作为奖励。

如果您不想自己进行这种抽象，那么有一些项目（例如Antler）可以帮助您解决这个问题。当然，这意味着您将依次依赖这些框架，但是这些框架负责处理不同的 ORM（以及破坏该 ORM 中的更改），为您提供实际上永远不会更改的抽象和统一语法。

【讨论】：

【解决方案3】：

这通常是过度设计的结果，但如果您可以切换 ORM，最好将您的 ORM 封装在一个类中，该类的合同 AKA 公共/内部方法由您控制。这样，您可以简单地修改您的类（或者如果编程到接口，则注入不同的类）来切换 ORM。否则，您必须从所有代码中反实现直接 ORM 调用，并在其位置重新实现新调用，这可能会产生数百到数千行的变动，具体取决于项目的复杂性。

【讨论】：