2011-03-01 14 views
14

En MVC 3 agregaron un Dependency Resolver lo que he estado usando. Al responder a una pregunta alguien comentó, debe usar el complemento Ninject MVC 3.MVC 3 Dependency Resolver o Ninject MVC plugin?

Así que mi pregunta es ¿por qué usarlo sobre el integrado? Si es el camino a seguir, ¿cómo lo configuras?

Question

Así anterior es el enlace a la pregunta que le respondí.

Respuesta

13

La extensión Ninject.Web.MVC (o paquete Ninject.MVC3 NuGet) también usa internamente una resolución de dependencias. Entonces, básicamente está usando el mismo mecanismo. Pero hay varias razones para usar la extensión en lugar de implementar una propia resolución de dependencias:

  1. ¿Por qué implementar un propio resolvedor de dependencias cuando ya hay una extensión haciendo exactamente lo mismo? Usar la misma implementación que otros hace que sea mucho más fácil apoyarlo cuando tiene un problema. Además, cuanto más usando la misma implementación, más estable se vuelve. (Ver el punto 4).
  2. La extensión es mucho más que una resolución de dependencias. Consulte http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/ para obtener una lista de todas las características que vienen con la extensión.
  3. Agrega soporte para la desactivación rápida de objetos InRequestScope después de que la solicitud finalice de manera predeterminada. Esto evita que las aplicaciones con una carga pesada se ejecuten en una excepción OutOfMemory.
  4. El resolvedor de dependencias en su publicación y el de arriba tienen un problema. En algunas situaciones, con mucha carga, la aplicación se bloqueará y solo se mostrarán las páginas amarillas de la muerte hasta que se reinicie la aplicación. No me gusta responder todas las preguntas que vendrán en el futuro solo porque se usa un solucionador de dependencias defectuoso. Agregue al menos un .ToList() a GetServices
  5. El soporte para InRequestScope se eliminará en Ninject 2.4 para eliminar la dependencia de System.Web para reducir el número de objetivos de compilación. Este es un cambio radical. Pero los proyectos basados ​​en una de las extensiones web solo necesitarán un cambio muy minimalista para que vuelva a funcionar.InRequestScope seguirá estando disponible para los proyectos que usen una de estas extensiones. Las implementaciones personalizadas tendrán que agregar soporte ellos mismos.
+0

@Remo Gloor - ¿Cuál es la diferencia entre la extensión Web.MVc y Ninject.MVC3? – chobo2

+0

Es lo mismo. Guardábamos el nombre del paquete NuGet Ninject.MVC3 como existía antes. –

+0

@ Remo Gloor - Entonces, ¿es lo mismo entonces? – chobo2

15

ASP.NET MVC 3 proporciona un servicio de inyección de dependencias que se conectará a cualquier resolución de dependencia que elija implementar. El plugin Ninject MVC 3 es muy simple en su función porque todo lo que debe hacer es implementar los métodos de resolución de tipo definidos en System.Web.Mvc.IDependencyResolver y llamar a los métodos Ninject apropiados para devolver un tipo solicitado.

Si elige usar su propio IDependencyResolver y asociarlo a Ninject (o cualquier otro marco de inyección de dependencia), o elige usar el complemento Ninject MVC 3 disponible gratuitamente, es una distinción trivial.

Aquí hay un ejemplo completamente funcional de cómo podría verse un IDependenResolver enrollado a mano, compatible con Ninject. El plug-in de Ninject MVC 3 sería fundamentalmente muy similar:

public class NinjectDependencyResolver : IDependencyResolver 
{ 
    private readonly IKernel _kernel; 

    public NinjectDependencyResolver(IKernel kernel) { 
     _kernel = kernel; 
    } 

    public object GetService(Type serviceType) { 
     return _kernel.TryGet(serviceType, new IParameter[0]); 
    } 

    public IEnumerable<object> GetServices(Type serviceType) { 
     return _kernel.GetAll(serviceType, new IParameter[0]); 
    } 
} 

El punto clave aquí es que ASP.NET MVC no proporciona un marco de inyección de dependencias de pleno derecho; proporciona solo la capa necesaria para recuperar una instancia de tipo requerida por medio de un contenedor IoC (es decir, Ninject) en puntos específicos a lo largo de la canalización de solicitudes ASP.NET MVC (resolución del controlador, resolución de vista, etc.).

Nota: si alguno de los términos que utilicé no es del todo exacto, infórmenme.

+0

Eso se parece mucho a lo que tengo ahora (ver la otra publicación). Escuché (o creo que escuché) que hacerlo tú mismo sin el plugin mvc no matará las sesiones cuando uses nhibernate. – chobo2

+0

@ chobo2 Realmente no tengo ninguna experiencia con nHibernate o el problema que está describiendo, por lo que no puedo hablar con él específicamente. : [ –

+0

@ chobo2, quizás a lo que se refiere es a 'OnePerRequestModule' de Ninject, esto borrará todo lo que esté vinculado a InRequestScope tan pronto como finalice la Solicitud. También se ejecutará antes de que se ejecuten otros manejadores de EndRequest. Lamentablemente, hacer esto usted mismo no evitará que esto suceda. – Vadim