In LINQ to Entities, creating a context

entity entity-framework linq linq-to-entities

Question

When constructing an entity context in their code, programmers have been known to use two alternative approaches.

The first is similar to this and is used often in MSDN code examples:

public void DoSomething() {
     using (TaxableEducationEntities context = new TaxableEducationEntities()) {
          // business logic and whatever else
     }
}

The second is to include your business logic in a class that contains the context as a private attribute. This is what it would look like:

public class Education_LINQ {

        private TaxableEducationEntities context = new TaxableEducationEntities();

        public void DoSomething() {
            var result = from a in context.luAction
                         select a;

            // business logic and whatever else
        }
}

Which approach is more effective?

Assume that you have two methods, one called DoSomething1() and another called DoSomething2(), and both methods incorporate the using statement to open the context and do whatever with it. Would there be any unnecessary cost if you called one method after the other given they both effectively establish the context before cleaning it up after they're done? rather to having a single private property that is generated when a class object is constructed and then deleted when the object is no longer needed?

1
27
5/31/2015 2:57:48 PM

Accepted Answer

There is "some" cost involved in creating a new ObjectContext every time. The overhead essentially consists of transferring metadata from a global cache into metadata connected to the particular ObjectContext.

When you take into account the additional safety that is built into the utilizing pattern and the fact that this overhead is quite minimal, it is often not anything to worry about.

Whichever option you choose relies on factors like:

  1. How long have you lived? How long will wrapping class last? If it endures, a for a very long period the ObjectContext develop to accommodate many entities decreasing with time. the new Every time, ObjectContext might be a a wise idea.
  2. Are calls to the synchronized methods on your wrapper class? If you adopt the second technique, you must ensure that your wrapped class or repository is thread safe if you anticipate having several threads call it since the ObjectContext class itself is not threadsafe.
  3. Do the methodologies really have nothing in common? If the methods share a context, you can have unanticipated side effects.

My general advise is to create a new context for each method if they are stateless, i.e. fire and forget.

A shared context would be a better option, however, if you have a stateful form that lasts just briefly.

UPDATE: I've taken the time to put together a more thorough response

41
10/4/2011 10:49:34 PM

Popular Answer

If that's what you mean, the second alternative really doesn't clean up after itself. Every time, I prefer the ObjectContext version since I don't have to dispose of it. I'm not sure if I get the question, however. I've been programming for too long.

public class UserManagerRepository : IUserManagerRepository, IDisposable
{
    private readonly Entities _context = new Entities();
    private bool _disposed;

    public User Create(User user, int countryId)
    {
        user.Country = GetCountry(countryId);
        _context.AddToUser(user);
        _context.SaveChanges();
        return user;
    }
}

Then, to utilize this repository, I do the following actions:

using(var repository = new UserManagerRepository())
{
    repository.Create(user);
}


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow