Iniezione delle dipendenze e Provider di Membership ASP.Net

Sono in procinto di creare un provider di appartenenze personalizzato per un sito Web ASP.Net MVC. Il provider viene creato come class separata come parte di una libreria più grande. È necessario che l’archivio dati di back-end sia flessibile in quanto potrebbe essere un file Xml o un database SQL. Il mio primo pensiero è stato quello di creare un’interfaccia per l’archivio dati e iniettarla nel provider usando l’iniezione di dipendenza.

Il risultato finale è richiesto è che uno sviluppatore possa ereditare l’interfaccia dell’archivio dati e fornire i metodi richiesti per aggiornare i dati, che verranno quindi utilizzati dai provider di appartenenza personalizzati.

Tuttavia, attraverso la mia mancanza di competenze, non riesco a capire come iniettare la class nel fornitore di appartenenze quando la aggiungo al sito web? Cosa è necessario fare per colbind l’archivio dati al provider? Quale sarebbe il modo più semplice per abilitare questo nel sito web?

Se si stanno configurando i provider di appartenenza personalizzati tramite l’elemento nel file Web.config, è ansible visualizzare i problemi che si avranno con l’integrazione delle dipendenze.

I provider sono costruiti e gestiti dal framework e non vi è alcuna possibilità per voi di intercettare tale costruzione per fornire un’iniezione di dipendenza aggiuntiva per l’interfaccia IDataStore .

Se la mia ipotesi è corretta, allora ciò che puoi fare è sovrascrivere il metodo Initialize() nel tuo provider personalizzato e fare l’iniezione delle dipendenze lì. È ansible avere un’impostazione nome / valore personalizzata nella configurazione del provider che punta a un tipo che implementa IDataStore , che viene passato come parte di un dizionario al metodo Initialize() .

Quindi, si triggers un’istanza del tipo di archivio dati e la si imposta sulla proprietà appropriata:

 public class MyMembershipProvider : MembershipProvider { public IDataStore DataStore { get; set; } public override Initialize(string name, NameValueCollection config) { var dataStoreType = config["dataStoreProvider"]; if (!String.IsNullOrEmpty(dataStoreType)) { var type = Type.GetType(dataStoreType); DataStore = (IDataStore) Activator.CreateInstance(type); } } } 

Initialize() verrà chiamato dal framework dopo che costruisce un’istanza del tuo provider, quindi è il posto perfetto per eseguire qualsiasi lavoro di installazione aggiuntivo come questo.

Per gli scenari di test, basta impostare la proprietà dell’archivio dati sull’istanza del provider stesso, poiché la si costruisce direttamente nei test.

Non è meglio? Lo uso con MVC3 e ninject. È sufficiente aggiungere una proprietà alla class del provider di appartenenza personalizzato. Ricordati di aggiungere “using System.Web.Mvc;” in cima.

 public IRepository Repository { get { return DependencyResolver.Current.GetService(); } } 

Il modo più semplice per fare l’iniezione di dipendenza che ho visto (e in realtà l’unico che ho usato finora …) è di avere un costruttore della tua class dipendente che prenda l’interfaccia come parametro e assegnarlo a un privato campo. Se lo desideri, puoi anche aggiungere un costruttore “predefinito”, che si collega al primo con un valore predefinito.

Semplificato, sarebbe simile a questo:

 public class DependentClass { private IDataStore _store; // Use this constructor when you want strict control of the implementation public DependentClass(IDataStore store) { this._store = store; } // Use this constructor when you don't want to create an IDataStore instance // manually every time you create a DependentClass instance public DependentClass() : this(new DefaultDataStore()) { } } 

Il concetto si chiama “concatenamento del costruttore” e ci sono molti articoli sul web su come farlo. Trovo questo tutorial molto esplicativo del pattern DI.