In MVVM ViewModel o Model dovrebbero implementare INotifyPropertyChanged?

La maggior parte degli esempi MVVM su cui ho lavorato ha avuto l' attrezzo ModelINotifyPropertyChanged , ma nell'esempio CommandSink di Josh Smith implementa ViewModelINotifyPropertyChanged .

Sto ancora mettendo insieme cognitivamente i concetti di MVVM, quindi non so se:

• Devi mettere INotifyPropertyChangedil ViewModel per metterti CommandSinkal lavoro
• Questa è solo un'aberrazione della norma e non importa davvero
• Dovresti sempre avere l'attrezzo Modello INotifyPropertyChangede questo è solo un errore che verrebbe corretto se questo fosse sviluppato da un esempio di codice a un'applicazione

Quali sono state le esperienze degli altri su progetti MVVM su cui hai lavorato?

Direi il contrario, metto sempre il mio INotifyPropertyChangedsul mio ViewModel - non vuoi davvero inquinare il tuo modello con una caratteristica abbastanza specifica del WPF come INotifyPropertyChanged, quella roba dovrebbe stare nel ViewModel.

Sono sicuro che gli altri non sarebbero d'accordo, ma è così che lavoro.

Sono fortemente in disaccordo con il concetto secondo cui il Modello non dovrebbe implementare INotifyPropertyChanged. Questa interfaccia non è specifica dell'interfaccia utente! Informa semplicemente di un cambiamento. In effetti, WPF lo utilizza pesantemente per identificare le modifiche, ma ciò non significa che sia un'interfaccia utente. Lo confronterei con il seguente commento: " Una gomma è un accessorio per auto ". Certo che lo è, ma lo usano anche biciclette, autobus, ecc. In sintesi, non prendere quell'interfaccia come una cosa dell'interfaccia utente.

Detto questo, ciò non significa necessariamente che ritengo che il Modello debba fornire notifiche. In effetti, come regola generale, il modello non dovrebbe implementare questa interfaccia, a meno che non sia necessario. Nella maggior parte dei casi in cui i dati del server non vengono trasferiti all'app client, il modello può essere obsoleto. Ma se ascolto i dati del mercato finanziario, non vedo perché il modello non possa implementare l'interfaccia. Ad esempio, cosa succede se ho una logica non UI come un servizio che quando riceve un prezzo Bid o Ask per un determinato valore emette un avviso (ad es. Tramite un'e-mail) o effettua un ordine? Questa potrebbe essere una possibile soluzione pulita.

Tuttavia, ci sono diversi modi per raggiungere le cose, ma vorrei sempre discutere a favore della semplicità ed evitare la ridondanza.

Cos'è meglio? Definizione di eventi in una raccolta o modifiche delle proprietà sul modello di vista e propagazione al modello o con l'aggiornamento della vista intrinsecamente il modello (tramite il modello di vista)?

La linea di fondo ogni volta che vedi qualcuno che afferma che " non puoi fare questo o quello " è un segno che non sanno di cosa stanno parlando.

Dipende molto dal tuo caso e in effetti MVVM è un framework con molti problemi e devo ancora vedere un'implementazione comune di MVVM su tutta la linea.

Vorrei avere più tempo per spiegare i molti gusti di MVVM e alcune soluzioni ai problemi più comuni, per lo più forniti da altri sviluppatori, ma credo che dovrò farlo un'altra volta.

In MV-VM il ViewModel implementa sempre (modello non sempre) INotifyPropertyChanged

Dai un'occhiata al modello / toolkit del progetto MV-VM da http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx . Utilizza il DelegateCommandcomando per e dovrebbe essere un ottimo modello di partenza per i tuoi progetti MV-VM.

Penso che MVVM abbia un nome molto scadente e che chiama ViewModel un ViewModel fa perdere a molti un'importante caratteristica di un'architettura ben progettata, che è un DataController che controlla i dati indipendentemente da chi sta provando a toccarlo.

Se si considera il View-Model come più di un DataController e si implementa un'architettura in cui DataController è l'unico elemento che tocca i dati, non si toccherebbe mai direttamente i dati, ma si utilizza sempre DataController. DataController è utile per l'interfaccia utente ma non necessariamente solo per l'interfaccia utente. È per livello aziendale, livello interfaccia utente, ecc ...

DataModel -------- DataController ------ View
                  /
Business --------/

Finisci con un modello come questo. Anche l'azienda dovrebbe solo toccare i dati utilizzando ViewModel. Quindi il tuo enigma scompare.

Dipende da come hai implementato il tuo modello. La mia azienda utilizza oggetti business simili agli oggetti CSLA di Lhotka e ne fa un ampio usoINotifyPropertyChanged tutto il modello di business.

Il nostro motore di convalida si basa fortemente sulla notifica che le proprietà cambiano attraverso questo meccanismo e funziona molto bene. Ovviamente, se stai utilizzando un'implementazione diversa da quella degli oggetti business in cui la notifica delle modifiche non è così critica per l'operazione, potresti avere altri metodi per rilevare le modifiche nel tuo modello di business.

Abbiamo anche modelli vista che propagano le modifiche dal modello dove necessario, ma i modelli vista stessi ascoltano le modifiche del modello sottostante.

Sono d'accordo con la risposta di Paulo, l'implementazione INotifyPropertyChangedin Modelli è totalmente accettabile ed è persino suggerita da Microsoft -

In genere, il modello implementa le funzionalità che semplificano il collegamento alla vista. Questo di solito significa che supporta la notifica di modifica di proprietà e raccolta tramite le interfacce INotifyPropertyChangede INotifyCollectionChanged. Le classi di modelli che rappresentano raccolte di oggetti derivano in genere dalla ObservableCollection<T>classe, che fornisce un'implementazione INotifyCollectionChangeddell'interfaccia.

Anche se spetta a te decidere se vuoi quel tipo di implementazione o meno, ma ricorda:

Cosa succede se le classi del modello non implementano le interfacce richieste?

A volte hai bisogno di lavorare con oggetti del modello che non implementano i INotifyPropertyChanged, INotifyCollectionChanged, IDataErrorInfoo INotifyDataErrorInfointerfacce. In questi casi, potrebbe essere necessario che il modello di vista includa gli oggetti modello ed esponga le proprietà richieste alla vista. I valori per queste proprietà saranno forniti direttamente dagli oggetti del modello. Il modello di vista implementerà le interfacce richieste per le proprietà che espone in modo che la vista possa facilmente associarsi ai dati.

Tratto da: http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx

Ho lavorato in alcuni progetti in cui non abbiamo implementato i INotifyPropertyChangednostri modelli e per questo abbiamo dovuto affrontare molti problemi; la duplicazione non necessaria delle proprietà era necessaria nella VM e allo stesso tempo dovevamo aggiornare l'oggetto sottostante (con valori aggiornati) prima di passarli a BL / DL.

Dovrai affrontare i problemi specialmente se devi lavorare con la raccolta dei tuoi oggetti modello (diciamo in una griglia o un elenco modificabile) o modelli complessi; gli oggetti modello non verranno aggiornati automaticamente e dovrai gestire tutto ciò nella tua VM.

Ma a volte (come in questo testo del link di presentazione ) è il servizio, che fornisce all'applicazione alcuni dati online e quindi è necessario implementare la notifica che sono arrivati ​​nuovi dati o che i dati sono cambiati usando gli eventi ...

Penso che la risposta sia abbastanza chiara se desideri aderire alla MV-VM.

vedere: http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx

Nel modello MVVM, la vista incapsula l'interfaccia utente e qualsiasi logica dell'interfaccia utente, il modello della vista incapsula la logica e lo stato della presentazione e il modello incapsula la logica e i dati aziendali.

"La vista interagisce con il modello della vista attraverso l'associazione di dati, i comandi e gli eventi di notifica di modifica. Il modello della vista richiede, osserva e coordina gli aggiornamenti del modello, convertendo, convalidando e aggregando i dati necessari per la visualizzazione nella vista."

Direi nel tuo ViewModel. Non fa parte del modello in quanto il modello è agnostico dell'interfaccia utente. Il modello dovrebbe essere "tutto ECCEZIONATO dal punto di vista aziendale"

L'implementazione di INPC nei modelli potrebbe essere utilizzata se i modelli sono chiaramente esposti in ViewModel. Ma in generale ViewModel racchiude i modelli nelle sue classi per ridurre la complessità del modello (che non dovrebbe essere utile per l'associazione). In questo caso l'INPC dovrebbe essere implementato nel ViewModel.

Sto usando il INotifyPropertyChange interfaccia in un modello. In realtà, una modifica della proprietà del modello deve essere attivata solo dall'interfaccia utente o dal client esterno.

Ho notato diversi vantaggi e svantaggi:

vantaggi

Notifier è nel modello aziendale

1. Come per dominio guidato, è giusto. Dovrebbe decidere quando rilanciare e quando non farlo.

svantaggi

Il modello ha proprietà (qty, rate, commission, totalfrieght). Totalfrieght è calcolato usando qty, rate, cambio di commissione.

1. Quando si caricano i valori da db, il calcolo totale del frieght viene chiamato 3 volte (quantità, velocità, commissione). Dovrebbe essere una volta.

2. Se rate, qty è assegnato nel livello aziendale, viene chiamato nuovamente notificatore.

3. Dovrebbe esserci un'opzione per disabilitarlo, possibilmente nella classe base. Tuttavia, gli sviluppatori potrebbero aver dimenticato di farlo.

Penso che tutto dipenda dal caso d'uso.

Quando si dispone di un modello semplice con un sacco di proprietà, è possibile implementarlo INPC. Per semplice intendo che questo modello sembra piuttosto un POCO .

Se il tuo modello è più complesso e vive in un dominio di modello interattivo - modelli che fanno riferimento a modelli, abbonamento a eventi di altri modelli - avere eventi modello implementati come INPC è un incubo.

Mettiti in una posizione di qualche entità modello che deve collaborare con alcuni altri modelli. Hai vari eventi a cui iscriverti. Tutti sono implementati come INPC. Immagina quei gestori di eventi che hai. Un'enorme cascata di clausole if e / o switch clausses.

Un altro problema con INPC. È necessario progettare le app in modo che facciano affidamento sull'astrazione, non sull'implementazione. Questo in genere viene fatto utilizzando le interfacce.

Diamo un'occhiata a 2 diverse implementazioni della stessa astrazione:

public class ConnectionStateChangedEventArgs : EventArgs
{
    public bool IsConnected {get;set;}
}

interface IConnectionManagerINPC : INotifyPropertyChanged
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    bool IsConnected {get;}
}

interface IConnectionManager
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    event EventHandler<ConnectionStateChangedEventArgs> ConnectionStateChanged;
    bool IsConnected {get;}
}

Ora guarda entrambi. Cosa ti dice IConnectionManagerINPC? Che alcune delle sue proprietà potrebbero cambiare. Non sai quale di loro. In effetti, la progettazione prevede che solo IsConnected cambi, poiché il resto è di sola lettura.

Al contrario, le intenzioni di IConnectionManager sono chiare: "Posso dirti che il valore della mia proprietà IsConnected potrebbe cambiare".

Basta usare il INotifyPropertyChange nel proprio modello di visualizzazione e non nel Modello,

il modello di solito usa il IDataErrorInfoper gestire gli errori di convalida, quindi tieni il tuo ViewModel e hai ragione sulla tua strada MVVM.

Supponiamo che il riferimento dell'oggetto nella vista cambi. Come notificherai che tutte le proprietà saranno aggiornate per mostrare i valori corretti? Chiamare OnPropertyChangednella tua vista per tutte le proprietà dell'oggetto è spazzatura dal mio punto di vista.

Quindi quello che faccio è quello di lasciare l'oggetto stesso di notificare a nessuno quando un valore in una proprietà cambia, ea mio parere io uso attacchi come Object.Property1, Object.Property2e su. In questo modo, se voglio solo cambiare l'oggetto che è attualmente gestito a mio avviso, lo faccio OnPropertyChanged("Object").

Per evitare centinaia di notifiche durante il caricamento di oggetti, ho un indicatore booleano privato che l'ho impostato su true durante il caricamento che viene controllato dall'oggetto OnPropertyChangede non fa nulla.

Normalmente ViewModel implementerà il INotifyPropertyChanged . Il modello può essere qualsiasi cosa (file xml, database o persino oggetto). Il modello viene utilizzato per fornire i dati al viewmodel, che si propaga alla vista.

Vedere qui

Imho, penso INotifyPropertyChangeche il modello di view implementa e il modello potrebbe usare la notifica su un "livello" diverso.

ad es. con alcuni servizi documentali e un oggetto documento si ha un evento documentChanged che un modello di visualizzazione ascolta per cancellare e ricostruire la vista. Nel viewmodel di modifica è presente un cambio di proprietà per le proprietà del documento per supportare le visualizzazioni. Se il servizio fa molto con il documento al momento del salvataggio (aggiornamento della data di modifica, ultimo utente e così via), si ottiene facilmente un sovraccarico di eventi Ipropertychanged e basta solo un documento modificato.

Ma se utilizzi INotifyPropertyChangenel tuo modello, penso che sia una buona pratica trasmetterlo nel tuo modello di visualizzazione invece di iscriverti direttamente alla tua vista. In tal caso, quando gli eventi cambiano nel tuo modello, devi solo cambiare il modello di visualizzazione e la vista rimane intatta.

Tutte le proprietà, che sono vincolate alla mia vista, sono nei miei ViewModel. Pertanto, dovrebbero implementare l'interfaccia INotifyPropertyChanged. Pertanto, la vista ottiene tutte le modifiche.

[Usando il toolkit MVVM Light, li lascio ereditare da ViewModelBase.]

Il modello contiene la logica aziendale, ma non ha nulla a che fare con la vista. Pertanto non è necessaria l'interfaccia INotifyPropertyChanged.