WVF MVVM: INPC e comunicazione di mediazione tra modello di vista e modello

Question

Ho letto vari approcci per comunicare le modifiche nei dati del modello al modello di vista. Alcuni suggeriscono che il modello dovrebbe implementare, ove possibile, INotifyPropertyChanged, in modo che possa notificare il modello di visualizzazione delle proprietà modificate. Alcuni suggeriscono un livello di servizio tra modello e modello di vista, con il livello di servizio che implementa INPC, chiamate di metodo che vengono instradate attraverso questo livello di servizio al modello in modo che il livello di servizio notifichi il modello di vista.

Ritengo che quest'ultimo sia una revisione più granulare del primo e che abbia iniziato ad implementare INPC nelle mie classi modello. Sembra sbagliato perché

a) Ora devo scrivere un gestore di eventi nel mio modello di vista per le notifiche dal modello. Questo assume la forma di un lungo switch (propertyName) che imposta le proprietà corrispondenti sul modello della vista, facendo in modo che l'NPC venga nuovamente inviato verso l'alto. Mi sento come se stessi scrivendo un sacco di codice della piastra della caldaia qui.

b) Il modello di vista è ora accoppiato al mio modello tramite un gruppo di stringhe che sono regolate esclusivamente dalla convenzione e che nessuna 'interfaccia' definita. Per non parlare della difficoltà che questo causa gli IDE.

c) Il mio modello deve essere modificato per soddisfare questo contesto! E se fosse stato chiuso per qualche motivo? Ho pensato che modelli come questo fossero progettati per aumentare la riusabilità del codice & separazione delle preoccupazioni. Non solo questo, ma il codice richiesto per sparare agli eventi INPC è noioso e ripetitivo e non davvero astrattivo.

Sono davvero curioso di sapere come i professionisti di WPF affrontano questo problema, indipendentemente dalle proprietà di dipendenza, ecc. Ho la sensazione che mi manchi qualcosa. Non mi piace usare un framework come vorrebbe imparare "da zero". Sono stato via da WPF per un anno o due e lavorare con AngularJS mi ha fatto mettere in discussione i miei metodi qui.

Grazie!

Answer 1

Ai fini di questa risposta, chiamerò i "tipi di dati" delle classi dell'oggetto business.

Nella mia esperienza personale, guarda i modelli sono sempre legata ai tipi di dati. Devi avere proprietà dei tipi che vuoi visualizzare, quindi ci sarà sempre un riferimento dal namespace dei modelli di visualizzazione allo spazio dei nomi dei tipi di dati.

Quello che si chiama un modello (dalla descrizione nel commento) suona come i miei modelli di vista. I miei modelli di vista hanno proprietà, per lo più del tipo delle varie classi di tipi di dati e metodi, mentre le mie classi di tipi di dati mantengono solo le proprietà per la maggior parte ... sono solo possessori di dati e reporter di cambiamenti davvero.

Sembra che tu abbia l'impressione che l'interfaccia INotifyPropertyChanged esegua alcuni doveri tra il "modello" mentre lo chiami e le classi del modello di visualizzazione ... secondo me, che è opzionale al meglio ... dal INotifyPropertyChanged Interface pagina all'indirizzo MSDN:

L'interfaccia INotifyPropertyChanged viene utilizzata per notificare ai client, in genere ai client di associazione, che è stato modificato un valore di proprietà.

Pertanto, vedo l'interfaccia INotifyPropertyChanged come la 'linfa vitale' che va tra i vista ei modelli di visualizzazione e oggetti di dati.Alcuni sviluppatori preferiscono "avvolgere" ogni tipo di dati nel proprio modello di visualizzazione, ma preferisco implementare direttamente l'interfaccia INotifyPropertyChanged nei miei tipi di dati.

La ragione principale per cui faccio questo è che posso aggancio in questo framework nelle classi di raccolta personalizzate che ho. Ciò mi consente di avere collezioni che sono a conoscenza di eventuali modifiche apportate a qualsiasi proprietà in qualsiasi elemento della raccolta, tra le altre cose. Mi consente inoltre di creare la sincronizzazione dei dati nelle mie classi base, in modo che gli oggetti sappiano quando hanno delle modifiche.

Consente inoltre di risparmiare tempo nella creazione di classi di modelli di viste corrispondenti per ogni classe di tipi di dati. Perché due classi fanno ciò che si può fare? Non ho mai avuto bisogno di quel livello di separazione. Se ho capito bene, l'implementazione di questa interfaccia nelle classi del tipo di dati annullerebbe la necessità di eseguire il punto a).

Alcuni dei vostri punti b) ec) possono anche essere invalidata se è possibile utilizzare .NET 4.5 in quanto v'è un nuovo attributo CallerMemberNameAttribute che è possibile utilizzare per alimentare automaticamente il nome di ogni proprietà al gestore PropertyChanged . Ho trovato un buon articolo chiamato C# 5–Making INotifyPropertyChanged Easier con una buona descrizione a riguardo.

Ho scritto diverse applicazioni WPF su larga scala ora e alcuni framework e non ho mai avuto problemi con l'implementazione dell'interfaccia INotifyPropertyChanged nelle mie classi di tipi di dati. In effetti, non penso che avrei potuto scriverli nello stesso tempo se avessi dovuto implementare le classi del modello di visualizzazione wrapper per ogni classe di tipi di dati. Questo metodo mi è stato utile fino ad ora e ho intenzione di mantenerlo, finché non trovo almeno una soluzione migliore. Tuttavia, questo è solo un parere di uno sviluppatore e devi andare con quello che sembra giusto per te.