2015-12-14 17 views
13

Sto per effettuare una conversione del progetto Microsoft.AspNet.Identity.EntityFramework di Identity (v 2.0.0.0) in uno che utilizza NHibernate come macchina di persistenza. Il mio primo 'pietra d'inciampo' è questo insieme di repository nella classe UserStore:Perché così tanti repository in "UserStore" di ASP.NET Identity?

private readonly IDbSet<TUserLogin> _logins; 
private readonly EntityStore<TRole> _roleStore; 
private readonly IDbSet<TUserClaim> _userClaims; 
private readonly IDbSet<TUserRole> _userRoles; 
private EntityStore<TUser> _userStore; 

parametro Type TUser è costretto a IdentityUser<TKey, TUserLogin, TUserRole, TUserClaim>, e questo tipo ha una propria serie simile di collezioni:

public virtual ICollection<TRole> Roles { get; private set; } 
public virtual ICollection<TClaim> Claims { get; private set; } 
public virtual ICollection<TLogin> Logins { get; private set; } 

mio la vita sarebbe molto più facile se dovessi gestire un solo repository, di TUser, dato che ognuno di questi utenti si occupa già delle proprie cose. C'è una ragione importante per cui non posso semplicemente eliminare questi (per eliminare qualsiasi dipendenza da Entity Framework, come DbSet?

Potrei ideare la mia classe di repository al posto di DbSet per conformarsi a questo progetto di UserStore, ma io preferirei di gran lunga perdere solo loro e lasciare che ogni istanza utente prendersi cura dei propri crediti, ecc

+0

Esistono molti esempi di utilizzo di altre tecnologie di database con Identity Framework. EF è solo uno dei fornitori. Ad esempio, ci sono già 4 campioni esistenti di nibibati, vedi: http://www.nuget.org/packages?q=Tags%3A%22Identity%22+Tags%3A%22nhibernate%22 - Inoltre, c'è il codice sorgente ad alcuni di loro. Ad esempio: https://github.com/MatthewRudolph/Airy –

+1

Il primo, il più importante progetto che ho trovato per HNibernate mi ha costretto a usare chiavi di stringa, in un sistema altrimenti totalmente generico, uno standard che trovo inaccettabile, e sono stato incaricato con l'utilizzo della nostra persistenza personalizzata di NHibernate per la persistenza dell'identità, quindi ritengo sia la cosa migliore e più divertente da fare. Cercherò, naturalmente, di guardare in alto gli esempi da te citati per l'ispirazione, grazie. – ProfK

risposta

6

le ulteriori DbSet classi sono per la persistenza dei dati relativi ai sinistri, i ruoli e gli account di accesso di un utente, mentre il ICollection i campi sono le proprietà di navigazione che ti permettono di leggere i dati da queste tabelle attraverso l'utente attualmente selezionato

Se si sta per una conversione completa del framework Identity (e della velocità divina per voi), avrete bisogno di queste entità database per gestire questi dati.

È tuttavia possibile disporre di un singolo repository User che espone l'accesso alle proprie attestazioni, ruoli e accessi per renderlo un po 'più semplice.

+0

Quel repository per singolo utente è quello che mi chiedo perché non l'abbiano usato in primo luogo. "e dio speed to you" - grazie, questo è un compito molto interessante e impegnativo visto che è la prima volta che lavoro 'dentro' Identity e la prima volta che ho usato NHibernate. – ProfK

+0

Vuoi dire 'UserStore'? Penso che sia più una classe di servizio che un repository per esporre i metodi per gestire tutte le informazioni dell'utente. – Steve

+0

Intendo perché non hanno un singolo repository utente all'interno di 'UserStore', poiché hanno già un repository utente,' EntityStore ', basato su un' DbSet', e in EF, il caricamento e il salvataggio di un utente le raccolte associate possono essere tutte gestite da 'DbContext' e da' DbSet', quindi perché devono avere 'repository' per tutte le raccolte di oggetti utente? – ProfK