Instanciar um contexto em LINQ to Entities

Question

Eu vi duas maneiras diferentes que os programadores se aproximam ao criar um contexto entidade em seu código.

O primeiro é como tal, e você pode encontrar tudo isso ao longo dos exemplos de código MSDN:

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

A segunda é criar o contexto como um atributo privado em alguma classe que encapsula a lógica de negócios. Então você teria algo como:

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
        }
}

Que maneira é mais eficiente?

Suponha que você tem dois métodos, um chamado DoSomething1 () e outro chamado DoSomething2 (), e ambos os métodos de incorporar a instrução usando para abrir o contexto e fazer o que for com ele. Foram-lhe chamar um método após o outro, haveria qualquer sobrecarga desnecessária acontecendo, já que essencialmente ambos os métodos de criar o contexto e, em seguida, limpá-lo quando estiver pronto? Ao invés de ter apenas um atributo privado que é criado quando um objeto de classe é instanciado, e, em seguida, por sua vez limpas quando o objeto sai do escopo?

Answer 1

Criando um novo ObjectContext cada vez que envolve 'alguns' em cima. Essencialmente, a envolver a sobrecarga está copiando metadados a partir de um cache global em metadados associados ao específica ObjectContext.

Esta sobrecarga é relativamente menor, de modo que muitas vezes não vale cerca de preocupante, especialmente quando você considera a segurança adicionais inerentes ao padrão usando.

Para mim qual opção você escolher depende de coisas como:

1. Quanto tempo viveu é a sua classe de embrulho provável que seja? Se ele vive para uma muito tempo o poder ObjectContext crescer para segurar um monte de entidades abrandar ao longo do tempo. Assim, um novo ObjectContext cada vez que pode ser um boa idéia.
2. São chamadas para o métodos em sua classe de embrulho sincronizada? o ObjectContext classe em si não é threadsafe por isso, se você usar o segundo padrão que você precisa para se certificar de sua classe de embrulho / repositório é thread-safe se você esperar vários segmentos de chamá-lo.
3. Os métodos essencialmente alheios? Se assim você pode ter efeitos colaterais inesperados se eles compartilham um contexto entre os métodos.

Em geral a minha recomendação é que, se os métodos são apátridas, ou seja, fogo e esquecer um novo contexto para cada método é provavelmente uma boa idéia.

Se, no entanto você tem um formulário com informações de estado relativamente curta ou alguma coisa, então talvez um contexto compartilhado é uma idéia melhor.

UPDATE: Eu tenho tido o tempo para montar uma resposta mais completa

Answer 2

A segunda opção realmente não limpar depois de si mesmo se é isso que você quer dizer. Eu prefiro a utilizar a versão ObjectContext cada vez, porque eu não tenho para eliminá-lo depois. Não tenho certeza eu tenho o direito pergunta embora ... muitas horas de programação hoje.

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;
    }
}

Depois de usar este repositório eu fizer algo como:

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