¿Qué tan lejos llega Dependency Injection?

Question

Mi solución aplicación web se compone de 3 proyectos:

1. aplicación web (ASP.NET MVC) Capa de lógica de negocios
2. (Biblioteca de clases)
3. base de datos de capa (Entity Framework)

Quiero usar Ninject para administrar la vida útil del DataContext generado por el Entity Framework en el Database Layer.

La capa de lógica de negocios consta de clases que hacen repositorios de referencia (ubicados en la capa de la base de datos) y mi aplicación ASP.NET MVC hace referencia a las clases de servicio de la capa de lógica empresarial para ejecutar código. Cada repositorio crea una instancia del objeto MyDataContext de la Entidad marco

Repositorio

public class MyRepository 
{ 
    private MyDataContext db; 
    public MyRepository 
    { 
     this.db = new MyDataContext(); 
    } 

    // methods 
} 

clases de lógica de negocios

public class BizLogicClass 
{ 
    private MyRepository repos; 
    public MyRepository 
    { 
      this.repos = new MyRepository(); 
    } 

    // do stuff with the repos 
} 

Will Ninject manejar la vida de MyDataContext a pesar de la larga cadena de dependencias de la Web Aplicación a la capa de datos?

Answer 1

EDITAR

que tiene algunos problemas con él hace algún tiempo, pero ahora parece que funciona:

Bind<CamelTrapEntities>().To<CamelTrapEntities>().Using<OnePerRequestBehavior>(); 

En lugar de utilizar HttpModule, puede utilizar OnePerRequestBehavior y se hará cargo de manejo del contexto en la solicitud actual.

EDIT 2

OnePerRequestBehavior necesita ser registrada en web.config, porque depende demasiado HttpModule:

En IIS6:

<system.web> 
    <httpModules> 
    <add name="OnePerRequestModule" type="Ninject.Core.Behavior.OnePerRequestModule, Ninject.Core"/> 
    </httpModules> 
</system.web> 

Con IIS7:

<system.webServer> 
    <modules> 
    <add name="OnePerRequestModule" type="Ninject.Core.Behavior.OnePerRequestModule, Ninject.Core"/> 
    </modules> 
</system.webServer> 

RESPUESTA ANTERIOR

Es su responsabilidad disponer el contexto cuando no sea necesario. La forma más popular en ASP.NET es tener un ObjectContext por solicitud. Lo hago por tener HttpModule:

public class CamelTrapEntitiesHttpModule : IHttpModule 
{ 
    public void Init(HttpApplication application) 
    { 
     application.BeginRequest += ApplicationBeginRequest; 
     application.EndRequest += ApplicationEndRequest; 
    } 

    private void ApplicationEndRequest(object sender, EventArgs e) 
    { 
     ((CamelTrapEntities) HttpContext.Current.Items[@"CamelTrapEntities"]).Dispose(); 
    } 

    private static void ApplicationBeginRequest(Object source, EventArgs e) 
    { 
     HttpContext.Current.Items[@"CamelTrapEntities"] = new CamelTrapEntities();    
    } 
} 

Ésta es la regla de inyección:

Bind<CamelTrapEntities>().ToMethod(c => (CamelTrapEntities) HttpContext.Current.Items[@"CamelTrapEntities"]); 

Mi Repositorio toma ObjectContext en el constructor:

public Repository(CamelTrapEntities ctx) 
{ 
    _ctx = ctx; 
} 

Answer 2

sólo quiero mencionar que Autofac with the ASP.Net integration tienen la solicitud de por vida soporte integradoResuelva instancias en el RequestContainer y se eliminarán (si se implementa IDisposable) al final de la solicitud.

Usted debe hacer su clases DI amable, aunque:

public class MyRepository 
{ 
    private MyDataContext db; 
    public MyRepository(MyDataContext context) 
    { 
     this.db = context; 
    } 

    // methods 
} 

public class BizLogicClass 
{ 
    private MyRepository repos; 
    public BizLogicClass(MyRepository repository) 
    { 
      this.repos = repository; 
    } 

    // do stuff with the repos 
}