Ho una domanda sulla modellazione.
Introduzione rapida: sviluppo applicazioni a fini di vendita. L'applicazione ha utenti. Ogni utente può essere cliente, dipendente o amministratore dell'azienda.
Dipende da:
Cliente: solo account registrato e acquista prodotto da qualsiasi società registrata
L'account registrato dal dipendente e il proprietario dell'azienda gli assegnano un ruolo dipendente.
Proprietario dell'azienda - account registrato e negozio creato.
ma il proprietario dell'azienda potrebbe essere anche un cliente, proprio come un dipendente.
Sono arrivato con una relazione semplice
utente della classe
cliente di classe: utente
impiegato della classe: utente
class owner: user
In questo modo posso facilmente incapsulare la logica per ogni RUOLO? (il ruolo è una parola chiave) Nella peggiore delle ipotesi potrei mappare tutto in BD alla tabella per ogni sottoclasse.
O dovrei lasciare l'utente semplice e creare una gerarchia di ruoli che incapsuli la logica?
cliente classe ruolo classe utente: dipendente classe ruolo: classe ruoloOwner: ruolo
e con associazioni semplici potrei
user.AssignRole (new Employee (company));
user.Roles.where (x = > x è Employee) .DoSth ()?
BTW: potrei rinominare "ruolo" in "attore"
E riguardo la radice aggregata in entrambi i casi? Se utilizzo la stessa entità (utente) come cliente e stessa entità (utente) come dipendente.
Che cosa succede quando 2 o più persone usano la stessa entità nello stesso tempo con diversi limiti di confine (cliente, dipendente)?
La domanda principale è: è buona progettazione se un'entità database può essere mostrata in molti tipi?