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的代码。

99.（9）％的项目不需要。程序员似乎已经超越了月球，他们可以创建另一种抽象抽象。

为什么我要重新完成ORM已经给我的东西？

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

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

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

Answer 2

我知道这是一个古老的问题，但主题很有意思。

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

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

因此，抽象ORM并不是关于轻松切换ORM的能力，它更多的是将项目与外部依赖关系脱钩（由于其复杂性和持续开发，流行ORM中破坏变化的概率很高）。此外，拥有这样一个分离的架构，您将获得项目的可测试性作为奖励。

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

Answer 3

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

为何抽象ORM？

3 个答案: