Giorno,
Premessa
Piu che un problema pratico (è possibile implementare diverse soluzioni) è un problema di design poichè le soluzioni che mi vengono in mente non mi sembrano soddisfacenti. Dato che si tratta di uno scenario piu che comune, credo esista una sorta di pattern da seguire.

Problema
Mettiamo di avere un semplicissimo datastore (su sql server):
CLIENTI->FATTURE
e che voglia associare ad ogni user memorizzato anch'egli nello stesso DB con nelle tabelle messe a disposizione dall'SQLMembershipProvider, uno ed un solo cliente.
Lo scenario che vorrei ottenere in buona sostanza è che al login ogni user (che è anche un cliente) abbia accesso solamente ai suoi dati e che l'amministratore abbia accesso a tutte le informazioni ma che soprattutto sia in grado di associare gli users ai clienti.
Deve esserci quindi una sorta di collegamento tra gli users (tabella aspnet_mebership) e la tabella clienti.

Possibili soluzioni.
1: LA prima che mi è venuta in mente è stata proprio quella utilizzare come ID della tabella clienti il campo UserId di tipo UniqueIdentifier cosi da creare un collegamento uno a uno tra Clienti e Utenti. La cosa mi serve a poco visto che agli users accedo tramite le classi di asp.net (Membership) mentre ai clienti accedo tramite classi che utilizzano entityframework e nel .edmx non mi sembra nemmeno il caso di importare le tabelle del membership provider. L'altra cosa che non mi piace è che per la tabella Clienti sarei costretto ad utilizzare una strategia di ID diversa da tutte le altre tabelle le quali usano un campo identity autoincrementante.
2: Eliminare la tabella clienti, mettere tutte le informazioni nel profile e collegare la tabella fatture (e tutto il resto) direttamente alla aspnet_membership ma anche qui sarei costretto ad utilizzare quest'ultima in EF e soprattutto avrei un DB fortemente dipendente dal fatto di utilizzare asp.net e uno specifico membership provider.Peraltro non saprei nemmeno se la cosa sia fattibile.
3: La soluzione piu semplice ma anche la piu sporca di tutte, è quella di utilizzare un ulteriore campo USerId(guid)o anche username a questo punto, nella tabella clienti che indichi se e quale utente sia collegato a quel cliente ma anche in questo caso si presentano vari problemi come l'integrità referenziale (Non c'è nessun collegamento tra le tabelle e anche se ci fosse non avrebbe molto senso).

Cercando su internet ho visto che molti hanno questo problema e cercano soluzioni del tipo visto su, ma sembra che in queste soluzioni sia nascosto un problema di design in quanto chi risponde premette sempre una sorta di "non vedo a cosa possa servire ma si fa cosi...".
Esiste un modo pulito per associare gli users ai clienti senza "legare" tra loro le tabelle della membership provider e il resto del database (le cui logiche fino a buona parte dello strato di business non dovrebbero di fatto nemmeno sapere che l'applicazione gira su aspnet e tamtomeno il tipo di membership provider utilizzato)?

Michele.

Precisazione, nel punto 3, ovviamente, non ha senso replicare lo UserName nella tabella Clienti perchè già contenuto nella tabella aspnet_Users.

Imvho, concordo pure io con fabrica

michele_p ha scritto:

thx

Di nulla.
Considera che la struttura, in questo modo, è davvero semplice, con un paio di metodi risolvi tutto.