Qual è una buona pratica per dividere i presentatori in un modello di interfaccia MVP che è diventato troppo grande?

Question

Un problema che ho incontrato frequentemente di recente è il problema delle mie classi di presentatori che stanno diventando troppo grandi. Di solito, posso tagliare una grande classe normale senza saltare un colpo. Ma i presentatori a volte sono un po 'più difficili da abbattere, senza rendere il codice più difficile da seguire.

Soprattutto quando la pagina inizia a riempirsi di controlli orientati al CRUD. A volte divido i controlli, ma se sono influenzati da altri controlli la logica di coordinamento è complessa a sé stante. A volte divido l'elenco o il recupero dei dati della griglia, ma a volte ciò può avere insidie ??simili.

Esistono tecniche o regole empiriche o aree comuni che si desidera escludere dai relatori?

Answer 1

Di solito uso due approcci:

1. Estrai e delega le regole di business alle classi di dominio.
2. Partiziona la vista in controlli logicamente correlati, quindi crea una nuova interfaccia di visualizzazione per ogni partizione. È quindi possibile dividere il relatore lungo quelle stesse righe. Se la piattaforma utilizzata supporta gruppi di componenti di sottomaschera (controlli utente C #, frame Delphi, ecc.), Questo è un modo efficace per rendere i controlli riutilizzabili.

Aggiorna

Quando divido le viste, di solito inizio dividendo l'interfaccia e facendo in modo che il mio modulo implementi più interfacce.

public class ComplexForm: Form, ISubView, IOtherSubView
{
    ...
}

Quindi ho diviso il presentatore in tutte le viste che ho creato.

public class SubViewPresenter
{
    private ISubView subView;
    ...
}

public class OtherSubViewPresenter
{
    private IOtherSubView otherSubView;
    ...
}

Puoi fare un ulteriore passo avanti e spostare l'implementazione di ISubView e IOtherSubView sui controlli utente o lasciarla così com'è. Se stai utilizzando un modello vista passiva questo è un gioco da ragazzi poiché il modulo gestisce comunque solo la logica dell'interfaccia utente. Una volta diviso il relatore, cerco di evitare la comunicazione diretta tra i relatori. Se è necessaria una comunicazione, provo a farlo indirettamente tramite oggetti di dominio.

Answer 2

Prova a estrarre il codice che esegue attività al di fuori del passaggio dei dati al DAL o del push alla vista. Ad esempio, se è necessario eseguire aggiornamenti e-mail o eseguire la logica aziendale, provare a estrarli in classi separate. Mi occupo spesso dello stesso problema e ho cercato di spostare quanta più logica possibile nelle singole classi dominio / entità ed eseguire la convalida lì.

Spero che sia utile.