Gestione di diversi tipi di utente in un'applicazione

Question

Molte applicazioni Web a cui ho contribuito (principalmente ASP.NET), devono gestire più tipi di utenti diversi.

Supponiamo di avere un portale scolastico, che sia gli alunni che gli insegnanti utilizzano quotidianamente. Nella prima pagina dell'applicazione gli utenti incontrano quasi la stessa GUI tranne alcuni collegamenti ad alcuni strumenti a cui solo gli insegnanti hanno accesso. Diciamo che questo è uno strumento di messaggistica. Un insegnante può avere ruoli diversi che definiscono a chi può inviare l'insegnante.

Ad esempio:

• Un insegnante con il ruolo Publisher sono autorizzati a inviare a tutti nella scuola.
• Un insegnante senza ruoli aggiuntivi può solo inviare a tutti i suoi corsi.
• In futuro, i genitori potranno anche accedere a questo portale e visualizzare informazioni dettagliate sui propri figli.

Il problema che ho sempre trovato in è che il mio codice è sempre sempre ingombra di if -statements durante la manipolazione di diversi tipi di utenti in tutto l'applicazione. Non solo per i diversi tipi di utenti, ma anche per le diverse regole aziendali. Sento che non riesco a trovare alcun modo per gestire correttamente diversi tipi di utenti.

Immagino che il concetto di ruoli in ASP.NET risolva questo problema, ma si finirebbe comunque con gli if -statements intorno all'applicazione.

La mia domanda è: Esiste qualche best practice su come gestire diversi utenti/tipi di utenti in un'applicazione senza infettare il codice con gli stati if?

Answer 1

È necessario suddividere queste responsabilità (ad esempio le capacità di invio di un insegnante, ad esempio). Puoi farlo usando il modello di strategia.

Quindi un insegnante ha una proprietà di pubblicazione aggiuntiva, che funge da interfaccia. L'implementazione può avere più realizzazioni (ad esempio NoPublishing per un insegnante che non ha funzionalità di pubblicazione o DefaultPublishing). Ogni insegnante può avere la sua proprietà Publishing impostata su NoPublishing o DefaultPublishing. Può anche essere modificato durante l'esecuzione, se necessario.

Un esempio:

public class Teacher 
{ 
    public IPublishing Publishing { get; } 
} 

interface IPublishing 
{ 
    void Send(); 
} 

public NoPublishing : IPublishing 
{ 
    public void Send() 
    { 
    // Implementatation 
    } 
} 

public PublishDefault : IPublishing 
{ 
    public void Send() 
    { 
    // Send a message the default way 
    } 
} 

Creare un insegnante:

var teacher = new Teacher(); 

Creare una strategia editore.

var defaultStrategy = new PublishDefault(); 

Collegare loro

teacher.Publishing = defaultStrategy; 

Ora è possibile inviare un messaggio da:

teacher.Publishing.Send(); 

A seconda di quale strategia editoriale è stato collegato sarà o inviare nulla o inviare qualcosa nel modo predefinito .

È sufficiente creare un'istanza di ogni strategia di pubblicazione utilizzata una sola volta e riutilizzarla per ciascun insegnante (o anche per altre classi che devono essere in grado di inviare).

Quando è necessaria un'altra funzionalità di pubblicazione, è sufficiente aggiungere una nuova strategia (ad esempio SmsPublishing, LetterPublishing ecc.).

È anche possibile modificare la strategia al volo, se necessario (riassegnando la proprietà Publishing).

Perché non implementare l'interfaccia non direttamente in Insegnante?

• Principio di separazione dei dubbi: IPublish contiene una responsabilità specifica e diversa.
• Forse IPublish contiene funzionalità che possono essere utilizzate in seguito in diverse classi o anche in altri progetti, quindi è più riutilizzabile.
• Il test è più semplice poiché IPublish non ha bisogno di alcuna conoscenza sull'insegnante.
• Possibilità di modificare in tempo reale il comportamento della pubblicazione in Insegnante.

(nota: non ho un compilatore qui, quindi il codice è solo a scopo esplicativo).