MembershipProvider personalizzato con interfaccia web e DAL

Question

sto lavorando su una soluzione ASP.NET con 2 progetti. Uno è l'interfaccia web e l'altro contiene la mia logica di business. Sto usando LINQ to SQL per il mio accesso ai dati nel secondo progetto.

A parte il mio database, ho una tabella chiamata Users che detiene le informazioni dell'utente.

Ho iniziato a implementare un MembershipProvider. Ho notato che MembershipUser è accoppiato con MembershipProvider. Qual è il modo più corretto di ottenere il mio BLL / DAL parlare di utenti? Devo minimamente implementare MembershipUser e ogni volta che un utente chiama un metodo, ma sarà per es. GetUserInfo () nel mio BLL / DAL, per ottenere informazioni complete su l'utente?

O devo fare i metodi della classe MembershipUser chiamano My Custom "Utenti" metodi di classe (come un wrapper) nel BLL / DAL (questa classe gli utenti personalizzati non è legato alla LINQ)?

O posso in qualche modo estendere la classe LINQ to SQL "CFUsers" per estendere MembershipUser.

Spero che questo ha un senso.

Answer 1

Io di solito vedo questo un entità separate come MembershipUser ruota intorno appartenenza, che è una preoccupazione generica e un utente nel sistema ruota attorno qualunque sia il vostro dominio comporta, io vedo il tuo punto di vista in cui entrambe queste entità potrebbero essere contenute in un unico, così. Profili è sicuramente il modo più semplice per andare.

C'è un WALKTHROUGH sui documentazione MSDN a http://msdn2.microsoft.com /en-us/lib...US,VS.80).aspx e un buona procedura dettagliata di Scott Guthrie a http://weblogs.asp.net/scottgu/archi. ..18 / 427754.aspx

Come sempre Dipende da che cosa i vostri obiettivi sono. Aggiunta di profilo è un meccanismo semplice per i dati aggiuntivi. Richiede molto poco in termini di personalizzazione e rende le informazioni facilmente disponibili per l'applicazione web. Questo non può essere in cui si desidera archiviare questo tipo di dati; in caso contrario, si tratta di una non-soluzione.

Se questo non va bene, facendo un nuovo fornitore derivato da quello predefinito (per ereditare quello che hai già) è una grande opzione. e, naturalmente, l'ultimo http: // codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/