为什么要抽象 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 中的重大更改），为您提供实际上永远不会更改的抽象和统一语法。