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.