使用实体框架，首选方式

本文关键字：方式 框架 实体 | 更新日期: 2023-09-27 17:56:02

假设我们已经创建了实体模型，使用它的首选方法是什么？我个人无法下定决心..

  1. 使用模型适配器：

    public statiс Product[] GetProducts()
{
        using(Entities ctx = new Entities())
        {
                return ctx.Product.ToArray();
        }
}

Product[] ps = ModelAdapter.GetProducts();
// ...
ModelAdapter.UpdateProduct(p);
    • 看起来很整洁;
    • 但是，上下文有时会创建/发布很多，对象会与上下文失去联系;

  2. 就地使用上下文：

    using(Entities ctx = new Entities())
{
        Product[] ps = ctx.Product.ToArray();
        // ...
        ctx.SaveChanges();
}
    • 有效
    • 但是，代码变得混乱

  3. 混合模式，妥协？

  4. 扩展方法：

    using(Entities ctx = new Entities())
{
    Product[] ps = ctx.GetProducts();
    // ...
    ctx.UpdateProduct(p);
}

实际上，现在，我正在尝试方法#4，将实用程序方法实现为上下文的扩展。因此，我可以使用一个上下文，并对该上下文进行多次调用。

使用实体框架，首选方式

在开发 Web 应用程序时，我一直在使用每个 Web 请求创建的共享上下文。 然后，您可以使用"ModelAdapter"方法并保留封装，但仍在同一上下文上运行。我已经用了很多，没有遇到任何问题。

通常使用任何符合您需求、可维护且适合应用程序复杂性的内容。您应该考虑的几点：

  • 切勿在请求之间共享上下文，根据需要为每个请求、每个操作或每个方法使用上下文。
  • 如果要对应用程序进行单元测试，您会发现静态方法，有时还有扩展方法可能是一个问题。但是使用 EF 测试应用程序是一个单独的问题。
  • 如果要在单个工作单元中修改或插入更多项，您会发现每个方法的上下文不是您需要的
  • 许多开发人员喜欢使用存储库模式将对 EF 功能的访问与应用程序的其余部分分开。它有自己的优点和缺点。
通常，

我会选择一种实现，其中使用存储库模式抽象出处理 EF 的复杂性，但只要我需要它，上下文就会保持活动状态。（场景 3）

我所说的"只要我需要它"是指只要服务电话需要。我不希望ObjectContext在多个服务调用中持续存在，因为我需要处理其状态。创建新ObjectContext的成本可以忽略不计。

我认为在很多方面，您的ModelAdapter也抽象了 EF 的复杂性，但是基于其静态性质，如果您决定保留ObjectContext，您可能会/会在并发场景中遇到问题。现在的实现方式可能无法为您提供更复杂的查询所需的灵活性（例如，加入 Order<->OrderDetail<->产品）。

相关文章：