L'ereditarietà della tabella è l'approccio sbagliato

1

Se prendiamo le due entità sottostanti come nell'esempio.

public class Person
{
    public string Username {get;set;}
    public string DisplayName {get;set;}
}

public class Worker:Person
{
    public string Title {get;set}
    public int SecurityId {get;set;}
}

Quando qualcuno si registra per la prima volta con questa app, le informazioni di base verranno acquisite e verrà creata una persona. Una volta che un amministratore arriva, potrebbe voler assegnare un ruolo a questa Persona. Ora i ruoli nel senso di autorizzazione non sono in discussione, c'è un RoleProvider. Tuttavia, se faccio diventare qualcuno un lavoratore, alcuni dettagli aggiuntivi devono essere catturati. In che modo i nuovi dettagli vengono archiviati al meglio è ciò che è in questione.

  • Potrei avere una classe WorkerProperties con i campi e dare Person - > Lavoratore con una relazione di 0,1 e 1:

  • Potrei avere tutti i campi come parte di Person e inserire solo cosa è obbligatorio. In fase di runtime, l'accesso al ruolo Persone sarebbe necessario capire quali campi sarebbero richiesti.

  • Potrei creare un lavoratore come mostrato sopra. Ereditando dalla persona. Con questa opzione c'è il problema che il PK è il nome utente registrato con. Avrei bisogno di cambiare in qualche modo il discriminatore colonna generata da EF per modificare sostanzialmente il tipo di oggetto in Worker.

posta James 15.08.2014 - 17:55
fonte

1 risposta

3

"Operaio" è davvero un sottotipo? Se dici "sì", allora quella persona non può diventare nessun altro sottotipo di "Persona", poiché non puoi cambiare il tipo di un'istanza oggetto / entità senza ricrearla e cancellare quella vecchia.

Se non è davvero un sottotipo, ma davvero un altro 'ruolo' che una persona può prendere (e devo dire, 'Worker' suona davvero come un ruolo), usa un sistema di ruolo, quindi modella quello che una persona può fare come un'entità separata.

Il problema è uguale a se una persona dovrebbe avere sottotipi come "Dipendente" o "Cliente". Se lo progettate in questo modo, un Dipendente non può diventare un Cliente. Bene, in realtà il Dipendente può, naturalmente, ma nel DB non è possibile a meno che non si crei una nuova istanza di Cliente con gli stessi dati, che copia efficacemente l'istanza dell'entità Employee.

    
risposta data 15.08.2014 - 18:05
fonte

Leggi altre domande sui tag