c# - 如何在 EF 中使用存储库模式使用存储过程和复杂类型？

Question

在处理 Entity Framework 中的 Repository 模式时，我们如何使用存储过程和复杂类型？谁能举一个简单的例子。

另外，在什么情况下我们应该真正采用 Repository 模式？

提前致谢

Answer 1

我认为您没有理解为什么当 EF 已经通过 ObjectSet/DbSet 实现存储库模式时人们还要实现存储库模式？

流行的答案是因为许多教程建议您在没有正当理由的情况下使用它。 不使用 Repository 层而不是 ObjectSet/DbSet 是有充分理由的。不过，我会指出一些它更可取的原因。

默认过滤器在实际应用程序中有许多情况需要默认过滤器。例如停产的产品不卖。如果直接公开 Products ObjectSet/DbSet，如果有人忘记应用默认过滤器，就会出现问题。它还避免了逻辑的重复。您也可以稍后修改默认过滤器而不会破坏问题。

public IQueriable<Product> GetAll()
{
    return context.Products.Where(p => !p.IsDiscontinued);
}

软删除许多应用程序使用软删除，您在其中保留诸如 IsDeleted 之类的列，但实际上并未删除该行。现在 ObjectSet/DbSet 有一个 Delete 方法，但是一旦您调用此方法，它就会将 null 值分配给可为空的 FK 属性。你可能不想要这个。

public void Delete(Product product)
{
    // can apply any other logic here
    product.IsDeleted = true;
}

只读实体在许多情况下，其他应用程序负责创建、删除和更新实体，而您的应用程序仅显示实体。但在这种情况下，ObjectSet/DbSet 公开了不受支持的功能。这种情况下的另一个好处是使用 NoTracking 选项来减少实体实现时间。

在不公开实现的情况下切换数据访问 在某些情况下，LINQ 是不够的。在这里您可以使用原始 SQL 或 SP。当 EF 公开的功能不够时，拥有存储库将避免公开不同的查询/更新方法。

使用现有数据库当您无法创建 EF 能够处理的数据库时。现有表可能有 Sql Variant、XML 列。将条目复制到另一个表以及您需要处理的无数其他情况，以保持数据库的完整性。

这些技术可能不是万能的，但如果情况需要，它们会派上用场。我的建议是，不要直接进入存储库，你最好考虑添加另一个必要的抽象层来实现所需的功能。