Una vista e un modello dovrebbero comunicare o meno?

Questo è un argomento controverso in MVC / MVVM. Alcuni dicono che è OK per la Vista accedere direttamente ai Modelli, altri dicono che dovresti avvolgere i Modelli in ViewModels per astrarli dalla Vista. Personalmente non sono un fan di nessuno dei due approcci.

Uno degli obiettivi principali di MVC / MVVM è quello di disaccoppiare l'interfaccia utente, la logica aziendale e i dati. Quindi, tenendo presente questo concetto, consentire alla Vista di accedere direttamente ai Modelli crea una dipendenza che potresti non voler avere. D'altra parte, il wrapping dei Models in ViewModels è spesso noioso e non molto utile in quanto i ViewModels tendono ad agire semplicemente come un pass-through ai Models.

Mi piace l'approccio con cui i tuoi modelli implementano un'interfaccia particolare, chiamiamolo IModel. La classe ViewModel può quindi offrire istanze di oggetti che implementano IModel per l'utilizzo di Visualizzazione. The View semplicemente sa che funziona con oggetti IModel che ottiene dal ViewModel. Rimuove il codice wrapper ViewModel estraneo e nasconde l'implementazione concreta di IModel dalla vista. In seguito è possibile scambiare un'implementazione di IModel con un'altra senza influire sulla vista di un bit.

Sul Web, tutti chiamano il loro MVC di disaccoppiamento.

Alcune tecnologie, come C #, usano MVVM perché non c'è alcun collegamento tra la vista e nessun altro, tutto passa attraverso il localizzatore di servizi, vincola le variabili.

Sul puro MVC, la vista parla direttamente con il modello e viceversa. Il Controller è presente solo quando si verifica un cambiamento.

E poi, c'è quello chiamato PAC (Presentation Abstraction Control). In questa architettura, la vista e il modello non parlano tra loro. Il Controller è l'unico autorizzato a fare qualsiasi cosa con la Vista o il Modello. Le persone spesso confondono questo con MVC.

Vedrai una spiegazione migliore qui: link

Per me, l'obiettivo principale di un'architettura è di non impedire futuri tentativi di refactoring. In genere, le viste interagiscono direttamente con i modelli jives con questo requisito ed è relativamente chiaro quando non lo fa.

Quando una vista diventa troppo intima con un modello, un ViewModel può essere una cosa bellissima, ma di solito è il mio caso che le istanze in cui è richiesto siano in minoranza.

In MVC , Paul Hegarty ha torto. Il controller riguarda gli eventi utente, non le comunicazioni modello-vista. Nella classica MVC , la vista osserva (s) il modello (modello Observer).

Con l'intermediario che sta facendo la mediazione, lo schema dovrebbe essere chiamato MVP , e in effetti, la maggior parte di ciò che è presentato oggi come MVC, è in effetti più vicino a MVP.

Poi c'è MVVM che è qualcosa di simile ad entrambi, eppure un po 'diverso, ed esisteva molto tempo fa ... è meglio vederlo come due MVC / MVP legati insieme tramite viewmodel oggetto - il MVC "client" ha viewmodel come modello e MVC "server" ha come view view view view.

Dato che stai chiedendo del materiale in quelle conferenze di Stanford in particolare, vale la pena considerare due cose sulla posizione di Hegarty:

1. Come hai detto, sta insegnando un corso di Computer Sci di livello L00. Ci sono molti posti nelle sue lezioni in cui lui semplifica, glissa sui dettagli, o dice "fallo in questo modo", come probabilmente si deve quando si insegnano le basi, cioè devi padroneggiare le regole prima di poterle infrangere. / li>
2. La mia esperienza con l'SDK di iOS è che, dove non impone una rigorosa separazione tra View e Model, è strongmente orientata verso quel modello. Quando scrivi app iOS in particolare, aderire alla separazione della vista modello ti aiuta a scrivere codice in linea con le aspettative del framework. Esiterei a generalizzare le dichiarazioni di Hegarty sullo sviluppo su altre piattaforme o in generale.