Iscrizione .NET con modello di repository

Question

Il mio team sta progettando un modello di dominio che nasconderà varie origini dati diverse dietro un'astrazione unificata del repository. Uno dei principali driver di questo approccio è l'altissima probabilità che queste fonti di dati subiscano cambiamenti significativi nel prossimo futuro e non vogliamo riscrivere la logica aziendale quando ciò accade. Un'origine dati sarà il nostro database di appartenenza che è stato originariamente implementato utilizzando il provider di appartenenze ASP.Net predefinito. Il provider di appartenenze è legato allo spazio dei nomi System.Web.Security ma abbiamo una linea guida di progettazione che richiede che il nostro livello del modello di dominio non dipenda da System.Web (o da qualsiasi altra dipendenza di implementazione / ambiente) in quanto verrà utilizzato in ambienti diversi - né vogliamo che i nostri siti Web comunichino direttamente con i database.

Sto considerando quale sarebbe un buon approccio per riconciliare l'approccio MembershipProvider con la nostra architettura di livello n astratto. La mia sensazione iniziale è che potremmo creare un " DomainMembershipProvider " che interagisce con il modello di dominio e quindi implementa oggetti nel modello che si occupano del repository e gestiscono la convalida / la logica aziendale. Il repository implementerebbe quindi l'accesso ai dati utilizzando il nostro strumento di accesso ai dati / ORM (ancora indeciso).

Ci sono buchi evidenti in questo approccio: non ho lavorato a stretto contatto con la classe MembershipProvider, quindi potrebbe anche mancare qualcosa. In alternativa, esiste un approccio che ritieni possa soddisfare meglio i requisiti sopra descritti?

Grazie in anticipo per i tuoi pensieri e consigli.

Saluti, Zac

Answer 1

Sono passati 6 mesi da quando è stata posta la domanda e nessuno sembra essere stato in grado di fornire una risposta, quindi ho pensato di spiegare la soluzione che alla fine abbiamo scelto.

Fondamentalmente, abbiamo deciso di non utilizzare alcuna implementazione di MembershipProvider, invece utilizziamo il nostro servizio di iscrizione personalizzato in cima a un repository. È stato importante per noi mantenere il database aspnet_Membership esistente, quindi il nostro repository ha sostanzialmente duplicato la funzionalità SQLMembershipProvider integrata (almeno, gli aspetti di cui abbiamo bisogno) - inizialmente tramite Linq-to-SQL ma ora stiamo passando a NHibernate . Il piano è di sostituire il database dei membri entro un anno circa quando tutti i nostri siti Web vengono aggiornati per utilizzare il nuovo modello.

È stato possibile utilizzare un provider di appartenenze personalizzato ma alla fine è diventato evidente che era più semplice, più coerente e più gestibile utilizzare un'implementazione personalizzata. Stiamo ancora utilizzando la funzionalità di autenticazione dei moduli incorporata per verificare che un utente abbia effettuato l'accesso e per reindirizzare gli utenti che provano ad accedere ad aree sicure del nostro sito senza essere prima autenticati, ma abbiamo ignorato la funzionalità legata al provider del profilo .

In definitiva, i nostri sentimenti al riguardo sono che mentre il provider di appartenenze è uno strumento potente e facile da usare all'interno di ASP.Net, se non si adatta all'approccio più ampio utilizzato nella tua applicazione, vale la pena considerare un approccio alternativo.

Answer 2

Interessante, grazie per aver pubblicato la tua soluzione finale. Sono in una situazione simile, ma sto scrivendo un Membershipprovider personalizzato. Non so dove mettere il provider perché ha bisogno dell'accesso al DB e allo spazio dei nomi System.Web. Sembra che sia l'unica classe che viola tutta questa separazione del design delle preoccupazioni.