MVVM: come gestire l'interazione tra ViewModels nidificati?

Question

Sto sperimentando il modello MVVM spesso menzionato e in alcuni casi ho avuto difficoltà a definire limiti chiari. Nella mia applicazione, ho una finestra di dialogo che mi consente di creare una connessione a un controller. Esiste una classe ViewModel per la finestra di dialogo, che è abbastanza semplice. Tuttavia, la finestra di dialogo ospita anche un controllo aggiuntivo (scelto da un ContentTemplateSelector), che varia a seconda del particolare tipo di controller che viene connesso. Questo controllo ha il proprio ViewModel.

Il problema che sto riscontrando è che, quando chiudo la finestra di dialogo premendo OK, devo effettivamente creare la connessione richiesta, che richiede informazioni acquisite nella classe ViewModel specifica per Controller interna. Si sta tentando semplicemente di avere tutte le classi ViewModel specifiche del controller che implementano un'interfaccia comune che costruisce la connessione, ma il ViewModel interno dovrebbe davvero essere responsabile di questa costruzione?

La mia domanda generale è: ci sono schemi di progettazione generalmente accettati su come ViewModels dovrebbe interagire tra loro, in particolare quando una macchina virtuale "madre" ha bisogno di aiuto da una VM "bambina" per sapere cosa fare?

---

EDIT:

sono venuto su con un disegno che è un po 'più pulita di quanto mi è stato originariamente pensato, ma non sono ancora sicuro se è il modo 'giusto' per fare questo. Ho alcuni servizi di back-end che permettono a ContentTemplateSelector di guardare un'istanza di Controller e pseudo-magicamente trovare un controllo da visualizzare per il generatore di connessioni. Quello che mi ha infastidito è che il mio ViewModel di primo livello avrebbe dovuto guardare il DataContext per il controllo generato e inviarlo a un'interfaccia appropriata, il che sembra una cattiva idea (perché il View DataContext ha qualcosa a che fare con la creazione ? il collegamento)

finii con qualcosa di simile (semplificando):

public interface IController 
{ 
    IControllerConnectionBuilder CreateConnectionBuilder(); 
} 

public interface IControllerConnectionBuilder 
{ 
    ControllerConnection BuildConnection(); 
} 

io ho la mia classe ViewModel interna implementare IControllerConnectionBuilder e il controllore restituisce il ViewModel interiore. Il ViewModel di livello superiore visualizza quindi questo IControllerConnectionBuilder (tramite il meccanismo pseudo-magico). Mi infastidisce ancora un po 'il fatto che sia il mio ViewModel interno a eseguire l'edificio, ma almeno ora il mio ViewModel di livello superiore non deve conoscere i dettagli sporchi (non sa nemmeno che il controllo visualizzato sta usando un ViewModel).

Sono lieto di ulteriori pensieri se ci sono modi per ripulirlo ulteriormente. Non mi è ancora chiaro quanta responsabilità è "okay" per il ViewModel.

Answer 1

Un'opzione che funziona bene per l'interazione tra viewmodels consiste nel collegarsi direttamente alle classi observer che si trovano tra le classi viewmodel.

Answer 2

Penso che tu voglia rendere il tuo livello di primo livello ViewModel consapevole dell'esistenza dello NestedViewModel, ha senso da un punto di vista gerarchico, la vista principale contiene la vista figlio.

A mio parere, l'istinto è corretto, non sembra corretto che ViewModel nidificato esponga comportamenti avviati dalle azioni dell'utente al livello principale. Invece, il livello superiore ViewModel dovrebbe fornire comportamenti per la vista a cui è associato.

Ma prenderei in considerazione la possibilità di trasferire la responsabilità per la costruzione di una connessione in un ICommand e di esporre questo comando tramite il tuo livello principale ViewModel. Il pulsante OK nella finestra di dialogo principale sarà quindi associato a questo comando e il comando delegherà semplicemente al livello superiore ViewModel, ad esempio chiamando lo ViewModel.CreateConnection() quando viene eseguito.

La responsabilità del controllo nested è quindi puramente raccogliendo ed esponendo i dati al suo NestedViewModel, per il consumo da parte contenente ViewModel, ed è teoricamente più riutilizzabile in contesti diversi che richiedono le stesse informazioni da inserire (se any) - supponiamo che tu voglia riutilizzarlo per modificare le connessioni già create.

L'unica ruga sarebbe se i diversi tipi di NestedViewModel espongano un insieme di dati radicalmente diverso.

Per esempio, uno espone HostName e Port come proprietà, e un altro espone UserName e password.

In tal caso, potrebbe essere necessario eseguire alcune operazioni infrastrutturali per fare in modo che il livello superiore ViewModel.CreateConnection() funzioni correttamente. Anche se si dispone di una piccola quantità di tipi di controllo annidati, potrebbe non valerne la pena, e un semplice controllo e cast di tipo NestedViewModel può essere sufficiente.

Questo suono è valido?

Answer 3

Recentemente ho sperimentato con Unity (libreria Microsoft Enterprise) per utilizzare l'iniezione di dipendenza. Questa potrebbe essere una strada da percorrere quando si usano interfacce che definiscono completamente ciò che entrambi i modelli visivi non hanno bisogno l'uno dell'altro. MEF sarebbe un'altra opzione per l'iniezione di dipendenza di cui sono a conoscenza.

HTH