3

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

4

3 回答 3

3

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

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

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

您不应该这样做，实际上，您会产生更多问题，仅举几例：

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

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

于 2013-06-10T16:34:55.857 回答
3

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

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

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

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

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

于 2014-12-30T13:01:51.957 回答
2

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

于 2013-06-10T16:22:59.043 回答