Come utilizzereste Entity Framework (1.0) con Membership ASP.Net?

Question

Sto provando a progettare un modello di entità per un'applicazione che utilizza l'appartenenza ASP.Net per la sua autenticazione utente. Nella maggior parte degli schemi di database che creo, i record in genere finiscono correlati agli utenti tramite il campo UserId sulla tabella aspnet_users. Questo ha funzionato bene per me in passato, ma ora che sto usando EF, sto avendo alcuni problemi concettuali per capire come farò riferimento all'utente da un'entità.

Ad esempio, supponiamo di avere un'entità "post" che contiene una proprietà "postedBy". Mi piacerebbe essere in grado di ottenere il nome utente dell'utente che ha creato questo post con qualcosa come post.user.username, ma sono cauto nel creare un'entità basata sulla tabella aspnet_user per timore di creare un modello che consenta io ignoro la classe Membership quando apporto modifiche al database.

Ho considerato di lasciare solo il campo post.userId come guida e quindi richiedere che qualsiasi codice che ha bisogno di conoscere il nome utente usi quel guid per ottenere l'utente dalla classe Membership, ma che sembra "ineligante".

Qualcuno ha qualche raccomandazione per i modelli di modelli di entità che si integrano con l'abbonamento? Sarei ragionevolmente accadere con un'entità utente di "sola lettura".

Answer 1

Il mio consiglio è: "No".

Vorrei essere più specifico.

L'utilizzo di UserId come chiave esterna mappata collega il modello dell'entità non all'appartenenza ASP.NET in generale, ma al provider di appartenenze SQL in generale. Cosa succede se si desidera utilizzare l'autenticazione di dominio o OpenID?

Non fraintendetemi: il 99,9% delle volte è corretto legare i riferimenti DB con una chiave esterna. Diamine, potresti persino farlo qui, ma non mapparlo nel tuo modello di entità. È necessario mantenere un muro di separazione logica tra i provider di appartenenza e i propri dati. Accedete ai vostri dati attraverso l'EF. Si accede ai dati di appartenenza tramite l'API di appartenenza. Il fatto che vivano nello stesso DB perché si sta utilizzando il provider di appartenenze SQL è un dettaglio di implementazione.

Aggiornamento: Ho ampliato questa idea in a blog post.