c# - 为什么要抽象一个 ORM？

Question

我经常看到使用存储库模式来抽象 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 已经给我的东西？

Answer 1

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

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

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

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

如果您不想自己进行抽象，周围有一些项目(例如 Antler)可以帮助您。当然，这意味着您将依次依赖于这些框架，但此类框架负责处理不同的 ORM(并破坏该 ORM 中的更改)，为您提供实际上永远不会更改的抽象和统一语法。