MVVM standardizzazione

Question

Qualcuno in Silverlight posted che MVVM attualmente manca di standardizzazione in modo che ognuno ha il proprio sapore ..

Ecco perché io e un paio di ragazzi da WPF discepoli stanno attivamente discutendo quali elementi della MVVM che tutti erano d'accordo. Capisco perfettamente che abbiamo implementato il pattern in modi diversi e abbiamo mescolato i diversi pattern o creato il nostro pattern in base alle necessità del nostro progetto o per semplificare la vita degli sviluppatori .. Ma dimenticatevi di quelle difficoltà o delle necessità speciali del vostro progetto . Discutiamo delle regole standard del modello MVVM che tutti hanno concordato. Ho pubblicato anche some of my thoughts here.

Perché MVVM?

• Testabiltiy (ViewModel è più facile da test di unità di code-behind o eventi codice di condotta)
• chiara separazione tra UX progettista e sviluppatore
• Aumenta il “sfumabilità” della vista
• modello mai deve essere modificato per supportare le modifiche alla vista
• ViewModel deve essere modificato raramente per supportare le modifiche alla vista
• Nessun codice duplicato per aggiornare le viste

fanno e non in vista

• non dovrebbe contenere alcuna logica che si desidera verificare: Come Glenn ha detto che MVVM non è il codice esercizio contare, siamo in grado di scrivere codice in codice -dietro a. Ma non dovresti mai scrivere alcuna logica che vuoi testare. Ad esempio: se l'utente seleziona un paese, allora si desidera visualizzare l'elenco di stati o città nella propria vista. Questo è il requisito aziendale quindi è necessario disporre di un test unitario per verificare questa logica. Quindi, non dovresti scriverlo in code-behind.
• può essere un controllo o un modello dati
• Mantenere la visualizzazione il più semplice possibile. : Possiamo ancora utilizzare Data Trigger o Value Converter o Visual State o Blend Behivor in XAML con cura.
• uso proprietà associata se qualcosa non è associabile:

fanno e non in ViewModel

• connettore tra Mostra e modello
• Tenere stato di visualizzazione, valore di conversione (È possibile creare la struttura dati che si desidera visualizzare in ViewModel invece di utilizzare ValueConverter.Ad esempio: è necessario mostrare il nome anziché Nome e Cognome.Il modello può avere nome e cognome ma è possibile creare proprietà Nome in ViewModel.)
• Nessun riferimento forte o debole (tramite Interface) di Vista
• Fai VM come verificabile possibile (ad esempio, nessuna chiamata alla classe Singleton)
• No Control relativi Stuff in VM (Perché se si modifica la vista poi dovrai anche cambiare VM.)

Modello

• può essere modello di dati, DTO, POCO, Proxy Auto-generated di classe di dominio e interfaccia utente del modello in base a come si desidera avere la separazione tra servizio del dominio e Presentation Layer
• Nessun riferimento al ViewModel

avete qualche suggerimento o commento per questo?

Abbiamo un disaccordo nel nostro gruppo. Alcuni hanno detto che va bene avere l'interfaccia di View in ViewModel. Ma alcuni hanno detto che se View Model ha l'interfaccia di View, allora sarà il pattern MVP.

Uno dei nostri esperti MVVM dicono di MVVM Vs MVP

Visualizza => ViewModel

• MVVM la vista è direttamente legato alla ViewModel e parla al VM tramite associazione dati
• In MVP, la vista è vincolata a un modello che pende dal SupervisingController o non è vincolato per niente (vista passiva).

ViewModel => Visualizza

MVVM

1. INPC/associazione di proprietà
2. Eventi
3. Messaggi (Evento Aggregator/Messenger/RX-quadro)
4. attraverso un intermediario come un servizio
5. Tramite un'interfaccia
6. Attraverso i delegati (la vista passa i delegati alla VM che può utilizzare per richiamarla. Ad esempio, VM può esporre un metodo SetActions che le chiamate View passano delegate.

MVP

Nel caso MVP standard è colloqui Presenter ritorna alla visualizzazione tramite un'interfaccia, associazione dati, o tramite le proprietà nel caso di vista passivo. Con Passive View le proprietà non utilizzano l'associazione dati, invece i getter e setter della proprietà view vengono utilizzati per impostare direttamente il valore di controllo.

Cosa ne pensi di questa idea?

Pensi che sia corretto per ViewModel avere l'interfaccia di Visualizza?

Se volete aggiungere più allora siete i benvenuti per aggiungere ... :)

L'intera idea di questo post è quello di ottenere la stessa comprensione del modello MVVM in comunità.

Answer 1

Mi piace quello che hai scritto.Una delle cose che mi infastidisce di più è che molte persone sembrano avere il loro VM accoppiato molto strettamente al loro View - se lo fai allora potresti anche fare il vecchio XAML + whacked nel codice dietro cosa.

Il pattern che utilizzo è una leggera variante su MVVM (ma è quasi sempre la stessa). Personalmente mi piace avere il mio ViewModel assegnato alla vista come interfaccia - mantiene la separazione molto pulita. Questo ha un grande vantaggio quando si eseguono i prototipi, gli elementi visivi possono essere attivati ​​o disattivati ​​dalla vista con un impatto minimo o nullo su ViewModel.

Answer 2

Penso che la comunicazione tra View ViewModel tramite databinding sia ciò che rende MVVM il proprio modello rispetto ad altre separazioni di preoccupazioni. Non è tanto se sia BUONO o CATTIVO per il vm conoscere la vista tramite l'interfaccia, ma nel contesto della comunicazione del pattern utilizzato non è MVVM.

Alcune delle difficoltà nell'ottenere e mantenere gli standard risiedono nelle carenze e nella complessità di WPF e Silverlight, purtroppo. Tuttavia, quando ci sono più standard validi, inserisco il mio cappello di Martin Fowler e aggiungo una sezione "quando usarlo".

I vostri standard coprono problematiche trasversali come la localizzazione?

FWIW mi piace il contenuto di ciò che hai scritto e sono contento che hai postato qui ...

Cheers,
Berryl