7

Asp.Net MVC 1.0 plantillas de proyecto incluyen un clase AccountController, que apoya inyección constructor:inyectar un MembershipProvider en ASP.Net MVC AccountController

public AccountController(IFormsAuthentication formsAuth, 
    IMembershipService service) 
{ 
    FormsAuth = formsAuth ?? new FormsAuthenticationService(); 
    MembershipService = service ?? new AccountMembershipService(); 
} 

También se incluye un clase AccountMembershipService, y que también apoya la inyección de constructor:

public AccountMembershipService(MembershipProvider provider) 
{ 
    _provider = provider ?? Membership.Provider; 
} 

estoy seguro que muchos de ustedes han utilizado estos para las pruebas unitarias, pero mi objetivo es inyectar un SqlMembershipProvider usando Windsor, y así configúrelo en tiempo de ejecución usando los archivos Windsor xml en lugar de web.config. En otras palabras, Quiero utilizar la inyección de constructor para la clase AccountMembershipService, y quiero seguir utilizando el sistema integrado de Membresía ASP.Net 2.0. Solo quiero que la configuración del sistema de Membresía pase por Windsor IoC.

¿Esto es posible sin escribir mi propio MembershipProvider, o SqlMembershipProvider no funciona bien con IoC?

From MSDN: "El constructor SqlMembershipProvider es llamado por ASP.NET para crear una instancia de la clase SqlMembershipProvider como se especifica en la configuración para la aplicación Este constructor es no destinado a ser utilizado desde el código."

Creo Phil asked a very similar question, pero no tengo la experiencia suficiente para asimilar the answers que recibió.

Gracias por su ayuda.


ACTUALIZACIÓN: Para que quede claro, mi razón de abastecer MembershipProvider de la aplicación a través de DI es dar soporte a múltiples inquilinos. Cada inquilino tiene una base de datos aislada con ASP membership tables. DI me permite cambiar las cadenas de conexión en tiempo de ejecución y así mantener la aplicación núcleo independiente de qué base de datos se está utilizando para cada inquilino. Windsor es el control de la DI y "sabe" lo que el inquilino hace la solicitud a través url:
var url = HttpContext.Current.Request.ServerVariables["HTTP_HOST"]

Mike Hadlow talks about this technique here. Estoy tratando de integrar SqlMembershipProvider a su uso de este diseño COI.

Gracias de nuevo.

+0

Un detalle que puede soplar esta abierta: ¿cuál es la Afiliación .Proveedor en el constructor para AccountMembershipService? –

+0

.Provider es "El proveedor de membresía predeterminado para la aplicación expuesta utilizando la clase base abstracta System.Web.Security.MembershipProvider". –

+0

Si el constructor de AccountMembershipService obtiene un proveedor nulo, Membership.Provider devolverá el SqlMembershipProvider (instanciado por el tiempo de ejecución) en función de la configuración de web.config. Ese es el comportamiento que quiero reemplazar a través de Windsor. –

Respuesta

3

Suponiendo que haya sus proveedores de pertenencia configurado algo como esto:

<membership> 
    <providers> 
     <clear/> 
     <add name="www.tenant1.com" 
     type="System.Web.Security.SqlMembershipProvider, ..." 
     .../> 
     <add name="www.tenant2.com" 
     type="System.Web.Security.SqlMembershipProvider, ..." 
     .../> 
    </providers> 
</membership> 

que puede tener Windsor seleccionar al proveedor adecuado de esta manera:

var container = new WindsorContainer(); 
container.AddFacility<FactorySupportFacility>(); 
container.Register(Component.For<MembershipProvider>() 
    .LifeStyle.Transient 
    .UsingFactoryMethod(() => Membership.Providers[HttpContext.Current.Request.Url.Host])); 
... (your controller registrations, etc) 
+0

¡Funcionó como un amuleto! Gracias mausch. –

Cuestiones relacionadas