Approccio per la costruzione di modelli di vista in un'applicazione MVVM complessa

Question

Approccio per la costruzione di modelli di vista in un'applicazione MVVM complessa

#1 da (2 voti)

5

Ho difficoltà con il design in un'applicazione MVVM WPF. In alcuni corsi che ho preso, dicono che avere un sacco di parametri in un costruttore è un odore di codice, ma non affrontano mai come affrontarlo.

In un mio progetto recente abbiamo utilizzato l'iniezione di dipendenza per fornire servizi che seguono un modello di adattatore dati. Ciascuna di queste classi è focalizzata su un tipo, come fornitore, dipendente, dettaglio, preventivo, richiesta di preventivo, ecc.

In questa applicazione i modelli di visualizzazione di alto livello non fanno molto, ma ospitano diversi modelli di visualizzazione, quali: dettagli, allegati di file, note, selezione del fornitore e requisiti del fornitore. Il costruttore per il modello di visualizzazione dettagli non elaborati occupa quasi tutti i servizi del costruttore, ma utilizza solo quei parametri per costruire i modelli di visualizzazione figlio.

Non ha senso che il modello di vista principale possa conoscere un modello di vista di dettaglio, perché il modello di vista principale è responsabile solo della navigazione di primo livello. Quindi quale approccio può essere usato per comporre i modelli di vista di alto livello senza molti parametri di costruzione, o non è una cattiva pratica in questo caso perché i modelli di vista di alto livello sono responsabili della composizione dei modelli di visualizzazione di basso livello?

design-patterns constructors factory mvvm builder-pattern

posta Adam 17.08.2018 - 14:58

fonte

1 risposta

Leggi altre domande sui tag design-patterns constructors factory mvvm builder-pattern

Pratiche CSS: posizionamento negativo Ci sono dei costi associati all'inserzione della mia app nel marketplace di salesforce?

score 2 · Answer 1

Il nostro team ha avuto lo stesso problema con i modelli di vista nel framework MVC di ASP.NET. La composizione della gerarchia della vista iniziò a diventare complessa e, man mano che l'interfaccia utente si evolveva, dovevamo apportare modifiche sempre più in alto nella struttura del modello di vista, e poi propagare ulteriormente queste modifiche passando gli argomenti del costruttore.

Ci siamo resi conto che un modello di visualizzazione che rappresentava un'intera pagina Web aveva davvero bisogno di molte informazioni da più fonti. Anche in questo caso siamo stati in grado di riutilizzare i modelli di visualizzazione in più contesti, ma configurati in modo leggermente diverso.

Sono giunto alla conclusione che questi modelli di visualizzazione "di primo livello" rappresentavano realmente un caso d'uso nell'applicazione e avevano esigenze di inizializzazione diverse rispetto ai modelli di vista che rappresentavano parti di una pagina Web - singoli componenti.

Abbiamo introdotto oggetti di fabbrica del modello di vista specializzati nell'inizializzazione di modelli di viste complessi. I modelli che rappresentavano un singolo componente sullo schermo avevano meno dipendenze e siamo stati in grado di continuare a inizializzarli attraverso i parametri del costruttore.

Non c'era una linea chiara che si fosse incrociata dove abbiamo detto "abbiamo bisogno di una fabbrica di modelli di vista!" È diventato un istinto. Quando si inizializza un modello di visualizzazione diventa complesso, abbiamo spostato la logica di inizializzazione in un metodo factory, ma l'inizializzazione dei modelli di visualizzazione rimane responsabilità dei costruttori di ciascun modello di vista fino a quando non raggiungiamo tale punto.