CODEWITHSUNDEEP
c#entity-frameworkdesign-patternscoding-style
pabdulin
pabdulin

Reputation: 35255

Working with entity framework, preferred way?

Suppose we have created Entities model, what is preferred way to work with it? I'm personally couldn't make up my mind..

  1. Using ModelAdapter :

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



Product[] ps = ModelAdapter.GetProducts();
// ...
ModelAdapter.UpdateProduct(p);
    • looks neat;
    • but, context is created/released a lot sometimes, objects lose contact with context;

  2. Using context in place:

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

        // ...

        ctx.SaveChanges();
}
    • effective
    • but, code becomes messy

  3. Mixed mode, compromise?

  4. Extension methods:

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

Actually now, I'm trying approach #4, implementing utility methods as extensions to context. So I can use one context, and make many calls to this context.

Upvotes: 6

Views: 493

Answers (3)

Ladislav Mrnka
Ladislav Mrnka

Reputation: 364409

Generally use anything that fits your needs, that is maintainable and that fits to the complexity of your application. Few points which you should think about:

  • Never share context among requests, use a context per request, per action or per method depending on your needs.
  • If you want to unit test your application you can find that static methods and sometimes also extension methods can be a problem. But testing application with EF is a separate problem.
  • If you want to modify or insert more items in a single unit of work you can find that a context per method is not what you need
  • Many developers like to use the repository pattern to separate access to EF features from the rest of the application. It has its own pros and cons.

Upvotes: 2

Yannick Motton
Yannick Motton

Reputation: 36031

Typically I would go for an implementation where the complexities of dealing with EF are abstracted away by using the Repository pattern, but have the context alive as long as I need it. (Scenario 3)

By "as long as I need it" I mean as long as the service call takes. I don't want the ObjectContext to persist through multiple service calls, as I would need to deal with its state. The cost of creating a new ObjectContext is negligible.

I think in many ways your ModelAdapter also abstracts away EF complexities, however based on its static nature, you might/will run into problems in concurrent scenarios if you decide to persist the ObjectContext. The way it's implemented now might not give you the flexibility you need for more complex queries (joining Order<->OrderDetail<->Product for instance).

Upvotes: 0

Lee Gunn
Lee Gunn

Reputation: 8666

When developing web applications I've been using a shared context which is created per web request. Then you can use your "ModelAdapter" approach and retain encapsulation but still operate on the same context. I've used this a lot and haven't experienced any problems.

Upvotes: 6

Related Questions