Question

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

使用ModelAdapter：

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，将实用程序方法实现为上下文的扩展。所以我可以使用一个上下文，并对这个上下文进行多次调用。

Answer 1

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

Answer 2

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

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

Answer 3

通常情况下，我会选择使用Repository pattern来抽象处理EF的复杂性，但只要我需要它就可以使用上下文。（情景3）

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

我认为在很多方面你的ModelAdapter也会抽象出EF的复杂性，但是如果你决定坚持ObjectContext，那么根据它的静态性质，你可能/会遇到并发场景中的问题。现在实施它的方式可能无法为您提供更复杂查询所需的灵活性（例如，加入Order＆lt; - ＆gt; OrderDetail＆lt; - ＆gt; Product。）。

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

3 个答案: