Modellazione di utenti e ruoli

1

Sto lavorando con un sistema in ASP.NET MVC, con Entity Framework per ORM. L'applicazione ha i requisiti per consentire agli utenti di avere diversi tipi di ruoli e le regole di autorizzazione saranno diverse per ogni ruolo (.eg utente con ruolo A sarà in grado di vedere alcune pagine, il ruolo B vedrà alcune pagine diverse)

Nella maggior parte dei sistemi con cui lavoro in precedenza, questa relazione utente e ruolo verrà modellata come:

public class User
{
    //Omitted properties
    public List<Role> Roles { get; set; }
}

public class Role
{
    //Omitted properties
}

Tuttavia, in questo sistema, esistono altri requisiti che richiedono all'utente di avere proprietà diverse basate su ruoli diversi, ad esempio. ruolo Un utente avrà la proprietà A + B, l'utente del ruolo B avrà la proprietà C + D. Ogni utente, indipendentemente dal ruolo che ha, sarà comunque identificato da un ID comune (ID utente di Active Directory). E potrebbe esserci una situazione in cui un utente ha più di un ruolo

Mi chiedo quale sia il modo migliore per modellare questa relazione. Penso ad alcuni modi, ma non ne ho trovato uno che sia abbastanza buono:

Approccio 1 : ogni utente ha un profilo che contiene proprietà diverse da ruolo a ruolo:

public class User
{
    //Omitted properties
    public List<Role> Roles { get; set; }
    public List<UserProfile> Profile { get; set; }
}

public abstract class UserProfile
{
    //Common properties
}

public class RoleAUserProfile : UserProfile
{
    //Omitted properties
}

public class RoleBUserProfile : UserProfile
{
    //Omitted properties
}

public class Role
{
    //Omitted properties
}

Problemi: difficile da modellare con la prima API fluente del codice EF. Ho impostato un approccio di suddivisione in tabelle, ma ho sempre problemi con il profilo utente e la chiave astratti. Anche l'elenco dei profili utente in Utente non è chiaro. Quando voglio ottenere dati per un ruolo specifico, è necessario scorrere l'elenco, controllare uno per uno

Approccio 2 : diversa classe utente per diversi tipi di ruolo:

public class User
{
    //Omitted properties
    public List<Role> Roles { get; set; }
}

public class RoleAUser : User
{
    //Omitted properties
}

public class RoleBUser : User
{
    //Omitted properties
}

public class Role
{
    //Omitted properties
}

Problemi: impossibile gestire un caso con più ruoli di un utente. Anche la relazione di ereditarietà mi sembra imbarazzante

Approccio 3 : metti tutto in una classe utente:

public class User
{
    //Omitted properties

    //Role A properties

    //Role B properties

    public List<Role> Roles { get; set; }
}

public class Role
{
    //Omitted properties
}

Problemi: difficile da mantenere quando il numero di proprietà per ciascun ruolo è ampio, difficile da utilizzare (è necessario sapere quali proprietà appartengono ai ruoli da utilizzare correttamente)

Approccio 4 : simile all'approccio 1, ma invece di creare un nuovo profilo utente, inserisci i dati direttamente nella stessa classe di ruolo. Sembra imbarazzante per me

Qualche suggerimento su come modellare questa situazione? Forse ho complicato troppo le cose, ma non ho ancora trovato nessuna soluzione soddisfacente.

    
posta Phuong Nguyen 29.06.2015 - 12:05
fonte

2 risposte

1

Se una proprietà dipende solo dall'Utente, allora appartiene all'Utente; se dipende solo da un ruolo, appartiene al ruolo. Chiaramente, se dipende da Utente e Ruolo, appartiene a una classe che modella l'intersezione di Utente e Ruolo, ad esempio qualcosa come Profilo. Un utente può avere molti profili; molti profili possono riferirsi allo stesso ruolo, quindi è solo una normale entità di intersezione molti-a-molti.

    
risposta data 07.07.2015 - 13:21
fonte
0

Quali sono quegli attributi dipendenti dal ruolo? È strano per gli utenti avere diversi set di attributi, dal momento che possono cambiare i ruoli in un batter d'occhio. Che cosa farai con gli attributi del ruolo A quando l'utente non ha più il ruolo? Cancellali? Cosa succede se domani quell'utente cambierà il suo ruolo in A ?

Quindi, un approccio consiste nel mantenere un singolo profilo utente troppo gonfio con tutti i possibili dati utente. I dati non utilizzati sono nulli.

Il secondo approccio che vedo è creare oggetti Role per ogni utente separatamente e memorizzare gli attributi dipendenti dal ruolo in quegli oggetti Role. Per quanto riguarda la memorizzazione del database, puoi inserirli nella tabella pivot della relazione User-to-Role.

È adatto a te?

    
risposta data 02.07.2015 - 17:40
fonte