Implementazione MVP a livello UserControl

5

Sto cercando di capire come deve essere implementato MVP al livello UserControl . Pensavo di averlo fatto, ma alla fine ho letto un post sul blog che mi ha praticamente bloccato. Ora sono tornato all'inizio e non ho idea di come procedere.

Diciamo che il mio UserControl è qualcosa di semplice come due TextBox es e un ComboBox . Questo viene richiamato da un modulo principale (che ha una propria View e Presenter). Ora, il modo in cui comprendo MVP è che il Main Form Presenter deve richiamare un secondo relatore per gestire tutte le comunicazioni con UserControl che viene rilasciato lì.

Ed è qui che mi sento completamente perso. Le mie implementazioni precedenti di UserControl s (prima che apprendessi MVP) incorporavano sempre la logica dietro il controllo (ad esempio la selezione ComboBox cambierà l'etichetta di testo relativa a TextBox1 ). Pertanto, l'implementazione di UserControl viene eseguita trascinandola sul designer e quindi chiamando comandi come UserControl1.Update() o UserControl1.DisplayData(data) .

In qualsiasi% di terze parti% co_de, tutti i comandi a UserControl vengono eseguiti dai comandi al controllo. Non esiste un "presentatore" che deve essere invocato, ad esempio, quando rilascio un UserControl o un ComboBox o qualsiasi altro controllo WinForms sul mio modulo. Tuttavia hanno una logica interna che determina come vengono visualizzati e, nella sostanza del testing, dovrebbe avere una separazione "presentatore" su di esso da qualche parte .

I ho pensato che una buona soluzione sarebbe che il costruttore del mio ListView avrebbe creato un Presenter. Qualsiasi comando verso UserControl verrà delegato direttamente al Presenter. Ciò consentirebbe al mio UserControl di avere la propria logica di presentazione separata dalla sua "vista", in modo tale che io possa testarla e in modo tale che l'implementatore (il modulo principale) debba solo rilasciare il UserControl ed eseguire riceve come parte della sua logica di presentazione locale. UserControl ha la sua logica di presentazione lasciata invisibile all'implementatore.

E proprio quando pensavo di aver capito tutto, scopro che è una cattiva pratica (The Self -Aware View) . Quindi supplico le persone che lo capiscono meglio di me: come faccio a costruire un UserControl che mantenga la logica di presentazione invisibile all'utente finale, così che non debba costruire il presentatore di wrapping nel mio Main Form, < strong> senza violare i principi che Matt Wynne discute nel post collegato sopra?

O sto completamente fraintendendo il concetto di MVP qui?

    
posta Arclight 21.08.2013 - 18:09
fonte

1 risposta

3

Ho letto il post di blog di Matt Wynne che hai linkato e posso vedere da dove proviene parte della confusione. Quindi segnaliamo alcune differenze tra il suo articolo e la tua situazione.

  • La tua domanda è stata posta il 21 agosto 2013. L'articolo di Matt è stato pubblicato il 13 giugno 2007 .

  • Hai taggato la tua domanda con e < a href="/ questions / tagged / winforms" class="post-tag" title="mostra le domande taggate 'winforms'"> winforms , anche se penso che intendevi invece di winForms. Matt afferma la sua attenzione e l'esperienza è stata con ASP.NET.

Voglio sottolineare che siamo già a un consiglio datato eb) diverse tecnologie di interfaccia utente.

ASP.NET e il / i pattern MV* che supporta sono cambiati significativamente da allora. Allo stesso modo, gli utenti di Silverlight e WPF hanno generato molte indicazioni con l'utilizzo del modello MVVM e dell'associazione dati.

E come punto di riferimento, consiglierei di leggere gli articoli di Martin Fowler su Vista passiva e Controller di supervisione quali sono gli schemi che ha eliminato dal suo originale Pattern MVP .

Penso che la tua domanda sia più interessante quando guardi il punto di vista più ampio e chiedi "a cosa mi aiuta MV* per un framework?" E il principale motore di questa famiglia di modelli è incapsulare le aree che probabilmente cambieranno. In relazione a tale incapsulamento c'è il principio della responsabilità unica e ci assicuriamo che ogni componente possieda ciò che dovrebbe.

Incapsuliamo tutta la logica di visualizzazione nel livello View in modo da poter cambiare più facilmente la nostra tecnologia di interfaccia utente in un momento appropriato più avanti nel tempo. Allo stesso modo con Model e qualsiasi cosa tu scelga di usare con il livello intermedio.

Quindi la risposta alla tua domanda è mettere la logica di visualizzazione appropriata all'interno di quel livello per far funzionare la tua tecnologia. Se stai usando winForms, finirai con un sacco di code-behind per far funzionare il modulo. WPF supporta l'associazione dei dati e riduce significativamente la quantità di code-behind. La logica che hai inserito in View dovrebbe potenzialmente scomparire quando cambi le tecnologie dell'interfaccia utente.

Allo stesso modo, se hai regole di presentazione che non sono imposte dalla tecnologia dell'interfaccia utente, le regole verranno inserite nel tuo livello intermedio in quanto devono persistere nella tua prossima interfaccia utente.

Non intendo sminuire il fatto che ci sono differenze tra i modelli MV* e quelle differenze esistono per una buona ragione. Ma il loro sviluppo è stato guidato dalle esigenze di particolari tecnologie. Stai utilizzando tecnologie potenzialmente diverse, quindi utilizza il modello MV* appropriato per il tuo ambiente. I framework sono lì per facilitare il cambiamento futuro, non per maneggiare lo sviluppo attuale.

    
risposta data 23.08.2013 - 23:45
fonte

Leggi altre domande sui tag