使用实体框架，首选方式？答案

【问题标题】：Working with entity framework, preferred way?使用实体框架，首选方式？
【发布时间】：2011-05-10 12:10:50
【问题描述】：

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

使用模型适配器：

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



Product[] ps = ModelAdapter.GetProducts();
// ...
ModelAdapter.UpdateProduct(p);

看起来很整洁；
但是，有时会创建/释放很多上下文，对象会失去与上下文的联系；

就地使用上下文：

using(Entities ctx = new Entities())
{
        Product[] ps = ctx.Product.ToArray();

        // ...

        ctx.SaveChanges();
}

有效
但是，代码变得混乱

混合模式，妥协？

扩展方法：

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

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

【问题讨论】：

标签： c# entity-framework design-patterns coding-style

【解决方案1】：

在开发 Web 应用程序时，我一直在使用根据 Web 请求创建的共享上下文。然后您可以使用您的“ModelAdapter”方法并保留封装，但仍然在相同的上下文中操作。我已经使用了很多，并且没有遇到任何问题。

【讨论】：

每个请求的上下文是一个很好的方法，除非你有一些令人信服的理由不这样做。它也使设计在逻辑上保持简单 - 请求和 EF 上下文为 1:1。

【解决方案2】：

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

Never share context among requests，根据您的需要为每个请求、每个操作或每个方法使用上下文。
如果您想对您的应用程序进行单元测试，您会发现静态方法，有时还有扩展方法可能会成为问题。但是使用 EF 测试应用程序是 a separate problem。
如果您想在单个工作单元中修改或插入更多项目，您会发现每个方法的上下文不是您所需要的
许多开发人员喜欢使用存储库模式将 EF 功能的访问与应用程序的其余部分分开。它有自己的pros and cons。

【讨论】：

谢谢@Ladislav！这绝对是一个很好的问题总结。很多有用的信息和你周围的链接。

【解决方案3】：

通常我会选择一个实现，通过使用Repository pattern 抽象出处理 EF 的复杂性，但只要我需要它就让上下文保持活跃。（场景三）

“只要我需要”我的意思是只要服务调用需要。我不希望 ObjectContext 通过多个服务调用持续存在，因为我需要处理它的状态。创建一个新的ObjectContext 的成本可以忽略不计。

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

【讨论】：