MVP e granularità del presentatore

Question

Abbiamo utilizzato il modello MVP e Winforms con un discreto successo. Tuttavia, viene sempre visualizzata una domanda su MVP:

Che cos'è una buona granularità per i presentatori?

Quello che voglio dire è che con Winforms, una granularità di solito funziona abbastanza bene per i controlli dell'utente. In questo modo, è facile riutilizzare i controlli utente e usarli come elementi costitutivi durante la progettazione di GUI più complesse. Tuttavia, avere la stessa (fine) granularità con i presentatori sembra essere un problema.

Da un lato, avere presentatori a grana grossa ostacola la possibilità di utilizzare " plug-in " controlla e in qualche modo viola il principio DRY: più presentatori spesso devono implementare la stessa logica (popolare un elenco di clienti, ad esempio), che viene utilizzato da più controlli più complessi.

D'altra parte, presentatori a grana fine sembrano limitare la capacità di riutilizzare i controlli in diverse situazioni. Ad esempio, a volte una vista di modifica potrebbe dover salvare subito il cliente; a volte ha bisogno di collegarlo a qualcos'altro; a volte basta solo validarlo; e così via. Spesso dipende dal controllo più complesso. Ma c'è anche una buona dose di comportamento condiviso.

Si noti che, in entrambi i casi, è possibile ottenere 1-presenter-1-view. Cosa è considerato "quotazione 1" " modifiche.

Quali sono generalmente considerate le migliori pratiche per la granularità del presentatore utilizzando MVP e Winforms?

• Presentatori raffinati e comportamento personalizzabile attraverso opzioni o qualcosa del genere?
• Presentatori a grana grossa e riutilizzabilità dei presentatori bassi?
• Qualcos'altro?

Dichiarazione di non responsabilità: utilizziamo principalmente Controller di supervisione, ma penso che si applichi anche alla Vista passiva. Ci scusiamo anche per la lunga domanda.

Answer 1

Usiamo MVP in tutti i nostri clienti e questa è sicuramente una conversazione che si presenta in più di un'occasione. Quanto dovrebbe essere pulito il nostro codice dietro a classi e presentatori? Detto questo, abbiamo scelto di utilizzare l'approccio presentatore a grana grossa. Fondamentalmente, ogni modulo avrebbe il suo presentatore e otterrebbe e imposterebbe le proprietà di uno qualsiasi dei controlli su un particolare modulo usando la sua vista. Il popolamento dei controlli, ad esempio una chiamata a un db per popolare una casella combinata, si trova in una classe di servizio pubblico. Qualsiasi convalida dei dati immessi dall'utente si trova in una classe BO che può essere riutilizzata da qualsiasi e / o tutti i presentatori. Spero che questo aiuti.

Answer 2

Nel mio sistema CAD-CAM i miei presentatori non usano i controlli utente. I controlli utente risiedono nella vista che risiede in un assieme EXE che implementa la vista interfacce utilizzate dal relatore.

Se si desidera visualizzare un elenco di clienti, lo passo alla vista che ha un DisplayCustomerList e utilizza qualsiasi combinazione di controlli utente necessaria per visualizzare l'elenco dei clienti. Se più viste mostrano l'elenco dei clienti allo stesso modo, nell'assieme ExE / View condividono un controllo utente o una classe per farlo. Quella classe non va fuori da quell'assemblea.

Il nostro software è adattato per l'esecuzione di diversi tipi di macchine per il taglio dei metalli. Quindi poniamo molta enfasi sulla possibilità di strappare l'interfaccia utente e sostituirla con un'interfaccia utente completamente diversa (corrispondente a una macchina diversa). Tutte queste interfacce utente fanno riferimento allo stesso set di assiemi di base.

La gerarchia si presenta così

Visualizza EXE Implementazione del presentatore Assemblaggio comandi: i comandi vengono eseguiti dal presentatore che modifica il modello Interfacce del presentatore Assemblaggi di modelli

A lato sono assiemi caricabili che definiscono contenuti dinamici come quali tipi di file possono essere caricati, report, taglio di driver di dispositivo, ecc. Questi implementano varie interfacce presenti negli assiemi di modello

Una cosa che faccio è non impelmentare un presentatore di vista per ogni finestra di dialogo. Se la finestra di dialogo è strettamente associata a un comando, viene definita, creata e utilizzata insieme alla classe di comando. Occasionalmente un gruppo di comandi correlati condividerà una finestra di dialogo (gestione dei file, ad esempio).

La domanda essenziale che faccio quando utilizzo MVP è " Cosa succede se si desidera sostituire completamente i moduli con qualcos'altro? " ;. Le risposte a quella domanda identificheranno dove sei troppo dipendente da un particolare controllo utente o modulo motore.

Il problema più grande (e per il quale non ho una buona risposta) della mia configurazione è che gli IDE e le lingue attuali rendono molto semplice legare i controlli utente ai record del database. È così produttivo rispetto a qualsiasi altra configurazione che tende a dominare il design. Non ho dovuto affrontare molto il problema nella mia applicazione CAD-CAM, quindi non ho altra risposta che passare il set di dati alla vista e lasciarlo gestire. Questo sito presenta alcuni schemi che potrebbero essere utili in questa situazione.