Inyectar repository en un proveedor de membresía personalizado con Ninject

Intento inyectar un repository a un proveedor de membresía personalizado con ninject en MVC 3.

En MembershipProvider, he intentado lo siguiente:

[Inject] public ICustomerRepository _customerRepository{ get; set; } 

Y

 [Inject] public TUMembershipProvider(ICustomerRepository customerRepository) { _customerRepository = customerRepository; } 

En mi módulo de ninject intenté lo siguiente:

 Bind().ToConstant(Membership.Provider); 

Ninguno de los anteriores funciona.

Cuando uso (en global.asa)

 kernel.Inject(Membership.Provider); 

Juntos con

 [Inject] public ICustomerRepository _customerRepository{ get; set; } 

funciona, pero no tengo administración del ciclo de vida y esto causará un error “ISession is open” de NHibernate, porque el ISession es InRequestScope y el repository no lo es.

Puede usar los enfoques de @Remo Gloor en su publicación de blog sobre inyección de proveedor . Incluye 3 pasos:

  1. Agregue [Inject] a cualquier propiedad de su proveedor que necesite inyectar (aunque el patrón que muestra) crea una clase muy simple cuya única función es ser receptible para la inyección de propiedades y reenvía las solicitudes a una clase real implementada mediante inyección de constructor – vale la pena seguirlo)

     public class MyMembershipProvider : SqlMembershipProvider { [Inject] public SpecialUserProvider SpecialUserProvider { get;set;} ... 
  2. Cree un contenedor inicializador que implemente IHttpModule que IHttpModule al proveedor, lo que IHttpModule su creación: –

     public class ProviderInitializationHttpModule : IHttpModule { public ProviderInitializationHttpModule(MembershipProvider membershipProvider) { } ... 
  3. Registre el IHttpModule en sus RegisterServices : –

     kernel.Bind().To(); 
  4. no hay 4; Ninject se encarga del rest: IHttpModules todos los IHttpModules registrados, incluido el que ha agregado, durante la secuencia de inicio.

(No se olvide de leer los comentarios en la publicación de blog re lifetimes, etc.)


Finalmente, si estás buscando algo totalmente directo que lo resuelva limpiamente, prueba con esta respuesta @Remo Gloor


PD: un gran comentario sobre todo el desastre es que el Proveedor no es un Patrón de @Mark Seemann . (y el complemento obsoleto de su excelente libro: – Inyección de dependencia en .NET que te permitirá descifrar cómodamente estas cosas desde los primeros principios)

tuve este problema

un proveedor de membresía, rol y perfil personalizado en otro proyecto de MVC usando el repository, cada vez que llamo al proveedor el repository inyectado era nulo.

intenté llamar a kernel.Inject (Membership.Provider); en el método NinjectWebCommon registerServices (kernel de IKernel) pero obtuvo la excepción

El resultado es siempre nulo, porque asp.net tiene su propia propiedad estática para la membresía. Que es membership.provider. y esta instancia no es parte de la administración de instancias de instancias.

entonces use en PostApplicationStartMethod

aquí está la solución de cipto add to NinjectWebCommon the attrbute and method:

  [assembly: WebActivator.PreApplicationStartMethod(typeof(WebApp.App_Start.NinjectWebCommon), "Start")] [assembly: WebActivator.PostApplicationStartMethod(typeof(WebApp.App_Start.NinjectWebCommon), "RegisterMembership")] [assembly: WebActivator.ApplicationShutdownMethodAttribute(typeof(WebApp.App_Start.NinjectWebCommon), "Stop")] public static void RegisterMembership() { bootstrapper.Kernel.Inject(Membership.Provider); } 

El problema es que toda la infraestructura de Membresía es un código .NET “nativo” (System.Web.Security) que no conoce MVC y sobre el contenedor DI utilizado por MVC. La llamada estática a Membership.Provider devuelve el proveedor de membresía según la configuración; sin embargo, el tipo de proveedor especificado se crea una instancia con una simple llamada Activator.CreateInstance. Por lo tanto, la dependency injection no tiene ninguna posibilidad de activarse y establecer la dependencia de su repository en el resultado. Si configura explícitamente la instancia devuelta con Ninject, puede funcionar, porque explícitamente le dio a Ninject el objeto para establecer las dependencias. Incluso en este caso, solo puede funcionar con inyección de propiedad y no con inyección de constructor, porque la instancia es creada previamente por la configuración de membresía.

En resumen: no puede insertar dependencias fácilmente en el proveedor de membresía porque no se resuelve desde un contenedor de dependency injection. Creo que tienes 2 posibilidades:

  1. Usted crea un repository en el proveedor de membresía personalizado directamente o puede acceder a él por otros medios bajo demanda (donde el contexto web ya está presente).
  2. Usted sube un nivel más y verifica los componentes que usarían su proveedor de membresía e intenta cambiar allí (para usar un proveedor de membresía resuelto de su contenedor DI en lugar del Proveedor de Membresía no inicializado). Si este “componente superior” es la autenticación de formularios, entonces este artículo podría ser útil (utilizando la dependency injection con IFormsAuthentication y IMembershipService): http://weblogs.asp.net/shijuvarghese/archive/2009/03/12/applying- dependencia-inyección-en-asp-net-mvc-nerddinner-com-application.aspx

¿ Intentó resolver su repository “manualmente”, como en esta respuesta ?: Ninject: ¿Resolver un objeto por tipo _y_ nombre / identificador de registro ?