Entity Framework - Como devo instância meu “Entidades” objeto

Question

Eu sou um novato total no Entity Framework e ASP.Net MVC, tendo aprendido principalmente de tutoriais, sem ter uma compreensão profunda de qualquer um. (Eu tenho experiência em .Net 2.0, ADO.Net e WebForms)

Minha dúvida atual vem da maneira que eu estou instanciação meus Entidades objetos.

Basicamente eu estou fazendo isso em meus controladores:

public class PostsController : Controller {

    private NorthWindEntities db = new NorthWindEntities();

    public ActionResult Index() {
            // Use the db object here, never explicitly Close/Dispose it
    }
}

Estou fazendo isso como este, porque eu achei em algum blogue MSDN que parecia bastante autoritária-me que eu assumi esta era uma maneira correta.
No entanto, me sinto muito un-fácil sobre isso. Embora me salva um monte de código, eu estou acostumado a fazer:

using (NorthWindEntities db = new NorthWindEntities() {
}

Em cada método que precisa de uma conexão, e se esse método chama outros que vai precisar dele, ele vai passar db como parâmetro para eles. Isto é como eu fiz tudo com a minha ligação objetos antes de Linq-to-SQL existiu.

A outra coisa que me faz inquieta é que NorthWindEntities implementa IDisposable, que por meio de convenções eu deveria estar chamando-o de método Dispose (), e eu não sou.

O que você acha sobre isso?
É correto exemplo as Entidades objeto como eu estou fazendo? Deveria cuidar de suas conexões abrindo e fechando-os para cada consulta?
Ou devo ser descartar explicitamente com uma cláusula usando ()?

Obrigado!

Answer 1

Controlador si implementa IDisposable. Então você pode substituir Dispose e dispor de qualquer coisa (como um contexto de objeto) que você inicializar quando o controlador é instanciado.

O controlador só vive desde que uma única solicitação. Então, ter um uso dentro de uma ação e ter um contexto de objeto para todo o controlador é exatamente o mesmo número de contextos: 1

.

A grande diferença entre estes dois métodos é que a ação terá completado antes da visão tornou. Então, se você criar o seu ObjectContext em um usando instrução dentro da ação, o ObjectContext terão sido eliminados antes da visão tornou. Então é melhor você ter nada leitura do contexto que você precisa antes da conclusão da ação. Se o modelo que você passar para a vista é alguma lista preguiçoso como um IQueryable, você vai ter eliminado o contexto antes da exibição é processado, causando uma exceção quando as tentativas vista para enumerar o IQueryable.

Por outro lado, se você inicializar o ObjectContext quando o controlador é inicializado (ou escrever código inicialização lenta fazendo com que seja inicializado quando a ação é executada) e dispor do ObjectContext no Controller.Dispose, então o contexto ainda será em torno de quando a exibição é processado. Neste caso, é seguro para passar um IQueryable à vista. O Controlador será descartado logo após a exibição é processado.

Por fim, eu seria negligente se eu não salientar que provavelmente é uma má idéia para ter o seu controlador de estar ciente do Entity Framework em tudo. Olhar em usar um conjunto separado para o seu modelo e o padrão de repositório para ter a conversa controlador para o modelo. Pesquisa A Google irá transformar-se um pouco sobre isso.

Answer 2

Você está fazendo um bom ponto aqui. Quanto tempo deve o ObjectContext ao vivo? Todos os padrões e práticas livros (como Dino Esposito de Microsoft-NET-arquitetar-Applications ) dizer-lhe que um DataContext não deve viver por muito tempo, nem deve ser armazenado em cache.

Eu só estava me perguntando por que não tendo, no seu caso, uma classe ControllerBase (Eu não estou ciente da implementação MVC, então paciência comigo), onde o ObjectContext se iniciou uma vez por todas controlador. Especialmente pensar sobre o Identidade Mapa Pattern , que já está implementado pela Entity Framework. Mesmo que você precisa chamar outro controlador como seu PostsController, seria ainda trabalho com o mesmo contexto e melhorar o desempenho também.