MVVM e modello di servizio

Sto creando un'applicazione WPF usando il modello MVVM. In questo momento, i miei modelli di visualizzazione chiama il livello di servizio per recuperare i modelli (come non è rilevante per il modello di visualizzazione) e convertirli in modelli di visualizzazione. Sto usando l'iniezione del costruttore per passare il servizio richiesto al modello di visualizzazione.

È facilmente testabile e funziona bene con viewmodels con poche dipendenze, ma non appena provo a creare viewModels per modelli complessi, ho un costruttore con MOLTI servizi iniettati (uno per recuperare ogni dipendenza e un elenco di tutti i valori disponibili per associare ad un itemsSource per esempio). Mi chiedo come gestire più servizi come quello e avere ancora un modello di visualizzazione che posso facilmente testare unità.

Sto pensando ad alcune soluzioni:

1. Creazione di un singleton di servizi (IServices) contenente tutti i servizi disponibili come interfacce. Esempio: Services.Current.XXXService.Retrieve (), Services.Current.YYYService.Retrieve (). In questo modo, non ho un costruttore enorme con una tonnellata di parametri di servizi.

2. Creare una facciata per i servizi utilizzati da viewModel e passare questo oggetto nel ctor del mio viewmodel. Ma poi, dovrò creare una facciata per ciascuno dei miei modelli complessi, e potrebbe essere un po 'troppo ...

Quale pensi sia il modo "giusto" per implementare questo tipo di architettura?

In effetti, entrambe queste soluzioni sono pessime.

Creazione di un singleton di servizi (IServices) contenente tutti i servizi disponibili come interfacce. Esempio: Services.Current.XXXService.Retrieve (), Services.Current.YYYService.Retrieve (). In questo modo, non ho un costruttore enorme con una tonnellata di parametri di servizi.

Questo è essenzialmente il modello di localizzazione di servizio , che è un anti-modello. Se lo fai, non sarai più in grado di capire da cosa dipende effettivamente il modello di vista senza guardare alla sua implementazione privata, il che renderà molto difficile il test o il refactoring.

Creare una facciata per i servizi utilizzati da viewModel e passare questo oggetto nel ctor del mio viewmodel. Ma poi, dovrò creare una facciata per ciascuno dei miei modelli complessi, e potrebbe essere un po 'troppo ...

Questo non è tanto un anti-schema ma è un odore di codice. Fondamentalmente stai creando un oggetto parametro , ma il punto del modello di refactoring PO è quello di gestire i set di parametri che vengono usati frequentemente e in molti luoghi diversi , mentre questo parametro verrebbe usato solo una volta. Come accennato, creerebbe un sacco di codice gonfio senza alcun vantaggio reale e non funzionerebbe bene con molti contenitori IoC.

In effetti, entrambe le strategie di cui sopra trascurano il problema generale, ovvero che l' accoppiamento è troppo elevato tra modelli e servizi di visualizzazione . Nascondere semplicemente queste dipendenze in un localizzatore di servizi o in un oggetto parametro non modifica effettivamente il numero di oggetti da cui dipende il modello di vista.

Pensa a come testeresti uno di questi modelli di vista. Quanto sarà grande il tuo codice di installazione? Quante cose devono essere inizializzate affinché funzioni?

Molte persone che iniziano con MVVM provano a creare modelli di visualizzazione per un intero schermo , che è fondamentalmente l'approccio sbagliato. MVVM è tutto incentrato sulla composizione e uno schermo con molte funzioni dovrebbe essere composto da diversi modelli di vista, ognuno dei quali dipende solo da uno o pochi modelli / servizi interni. Se devono comunicare tra loro, lo fai tramite pub / sub (broker messaggi, bus eventi, ecc.)

Quello che devi effettivamente fare è riformattare i tuoi modelli di vista in modo che abbiano meno dipendenze . Quindi, se è necessario disporre di uno "schermo" aggregato, creare un altro modello di vista per aggregare i modelli di vista più piccoli. Questo modello di vista aggregata non deve fare molto da solo, quindi a sua volta è anche abbastanza facile da capire e testare.

Se lo hai fatto correttamente, dovrebbe essere ovvio solo guardando il codice, perché avrai modelli di vista brevi, concisi, specifici e testabili.

Potrei scrivere un libro su questo ... in effetti lo sono;)

Prima di tutto, non esiste un modo universalmente "giusto" per fare le cose. Devi prendere in considerazione altri fattori.

È possibile che i tuoi servizi siano troppo precisi. Avvolgere i servizi con le facciate che forniscono l'interfaccia che un Viewmodel specifico o anche un cluster di ViewModel correlati potrebbe utilizzare potrebbe essere una soluzione migliore.

Sarebbe ancora più semplice avvolgere i servizi in un'unica facciata utilizzata da tutti i modelli di visualizzazione. Naturalmente, questa può potenzialmente essere un'interfaccia molto grande con molte funzioni non necessarie per lo scenario medio. Ma direi che non è diverso da un router di messaggi che gestisce tutti i messaggi nel tuo sistema.

In effetti, ciò che ho visto alla fine evolvere in molte architetture è un bus di messaggi costruito attorno a qualcosa come il modello Event Aggregator. Il test è facile perché la tua classe di test registra un ascoltatore con l'EA e genera l'evento appropriato in risposta. Ma questo è uno scenario avanzato che richiede tempo per crescere. Dico di iniziare con la facciata unificante e andare da lì.

Perché non combinare entrambi?

Crea una facciata e inserisci tutti i servizi utilizzati dai tuoi viewmodels. Quindi puoi avere un'unica facciata per tutti i tuoi modelli di visualizzazione senza la brutta parola S.

Oppure puoi usare l'iniezione di proprietà invece dell'iniezione del costruttore. Ma poi, devi assicurarti che vengano iniettati correttamente.