Architettura pulita: che cos'è il modello di visualizzazione?

Nel suo libro "Clean Architecture", lo zio Bob afferma che il presentatore dovrebbe mettere i dati che riceve in qualcosa che chiama "Visualizza modello".

È la stessa cosa di 'ViewModel' dal modello di progettazione Model-View-ViewModel (MVVM) o è un semplice Data Transfer Object (DTO)?

Se si tratta non è un semplice DTO, come si relaziona alla vista? La vista riceve aggiornamenti da essa attraverso una relazione Observer?

La mia ipotesi è che sia più simile al ViewModel di MVVM, perché nel capitolo 23 del suo libro, Robert Martin dice:

Il lavoro di [Presentatore] è accettare i dati dall'applicazione e formattarli per la presentazione in modo che la Vista possa semplicemente spostarli sullo schermo. Ad esempio, se l'applicazione desidera visualizzare una data in un campo, consegnerà l'oggetto Presenter a Date. Il relatore formatterà quindi quei dati in una stringa appropriata e li posizionerà in una semplice struttura di dati chiamata modello View, dove la View può trovarli.

Ciò implica che la vista è in qualche modo connessa al ViewModel, invece di riceverla semplicemente come argomento di una funzione (come nel caso di un DTO).

Un altro motivo per cui penso che questo sia perché se guardi l'immagine, il Presenter usa il View Model, ma non la View. Considerando che il presentatore utilizza sia il confine di output che il DTO dei dati di output.

Se non è né un DTO né il ViewModel di MVVM, ti preghiamo di approfondire di cosa si tratta.

È la stessa cosa di 'ViewModel' dal modello di progettazione Model-View-ViewModel (MVVM)

No.

Sarebbe questo :

Questo ha cicli. Lo zio Bob ha accuratamente evitato i cicli .

Invece hai questo:

Che certamente non ha cicli. Ma ti sta chiedendo come la vista sia a conoscenza di un aggiornamento. Ci arriveremo tra un momento.

o è un semplice Data Transfer Object (DTO)?

Per citare Bob dalla pagina precedente:

Se lo desideri, puoi utilizzare strutture di base o semplici oggetti di trasferimento dati. Oppure puoi comprimerlo in un hashmap o costruirlo in un oggetto.

Clean Architecture p207

Quindi, certo, se vuoi.

Ma sospetto fortemente che ciò che ti sta veramente infastidendo sia questo :

Questo piccolo abuso di UML contrasta la direzione della dipendenza dal codice sorgente con la direzione del flusso di controllo. Qui puoi trovare la risposta alla tua domanda.

In una relazione di utilizzo:

il flusso di controllo va nella stessa direzione della dipendenza dal codice sorgente.

In una relazione di attuazione:

il flusso di controllo in genere va nella direzione opposta rispetto alla dipendenza dal codice sorgente.

Ciò significa che stai davvero guardando questo:

Dovresti essere in grado di vedere che il flusso di controllo non passerà mai dal Presenter alla Vista.

Come può essere? Cosa significa?

Significa che la vista o ha il suo thread (che non è così insolito) o (come sottolinea @Euforico) il flusso di controllo sta venendo alla vista da qualcos'altro non rappresentato qui.

Se è lo stesso thread, View saprà quando View-Model è pronto per essere letto. Ma se questo è il caso e la vista è una GUI, sarà difficile riverniciare lo schermo quando l'utente lo sposta mentre aspettano il DB.

Se la vista ha il proprio thread, allora ha il suo flusso di controllo. Ciò significa che per implementare ciò la Vista dovrà eseguire il polling del View-Model per notare i cambiamenti.

Poiché il relatore non sa che la vista esiste e la vista non sa che esiste il presentatore, non possono chiamarsi affatto. Non possono lanciarsi gli eventi a vicenda. Tutto ciò che può accadere è che il Presentatore scriverà sul View-Model e la View leggerà il View-Model. Ogni volta che ne ha voglia.

Secondo questo diagramma l'unica cosa condivisa da View e Presenter è la conoscenza del View-Model. Ed è solo una struttura di dati. Quindi non aspettarti che abbia alcun comportamento.

Ciò potrebbe sembrare impossibile ma può essere fatto funzionare anche se il View-Model è complesso. Un piccolo campo aggiornato è che tutta la vista dovrebbe eseguire il polling per rilevare una modifica.

Ora, naturalmente, puoi insistere sull'uso del modello di osservatore, o avere alcune cose di struttura nascoste che ti nascondono questo problema, ma ti preghiamo di capire che non è necessario.

Ecco un po 'di divertimento che ho illustrato il flusso di controllo:

Nota che ogni volta che vedi il flusso andare contro le direzioni che ho definito prima, quello che vedi è una chiamata che ritorna. Questo trucco non ci aiuterà a raggiungere la vista. Bene, a meno che non torniamo prima a ciò che viene chiamato il Controller. Oppure potresti semplicemente cambiare il design in modo da poter arrivare alla vista. Ciò risolve anche quello che sembra l'inizio di un problema yo-yo con Data Access e la sua interfaccia.

L'unica altra cosa da imparare qui a parte questo è che Use Case Interactor può praticamente chiamare le cose nell'ordine che desidera fintanto che chiama l'ultimo presentatore.

Trovo questo problema troppo confuso e ci vorrebbe un sacco di testo e tempo per spiegare correttamente il problema poiché credo che fraintendiate sia Martin Architecture Clean sia MVVM.

La prima cosa da notare è che il diagramma che hai pubblicato è incompleto. Mostra solo "business logic", ma manca una sorta di "orchestrator" che in realtà fa muovere le parti nell'ordine giusto.

Il codice dell'orchestratore sarebbe semplice come

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

Credo di aver sentito Martin parlarne in uno dei suoi discorsi su Clean Architecture.

Un'altra cosa da sottolineare è che l'osservazione di candied_orange sulla mancanza di cicli è sbagliata. Sì, il ciclo non esiste (e non dovrebbe) nell'architettura del codice. Ma i cicli tra le istanze di runtime sono comuni e spesso portano a una progettazione più semplice.

Questo è il caso di MVVM. In MVVM View dipende da ViewModel e ViewModel utilizza gli eventi per notificare a View le sue modifiche. Ciò significa che nella progettazione delle classi esiste solo dipendenza dalle classi View to Model, ma durante il runtime esiste una dipendenza ciclica tra le istanze View e ViewModel. Per questo motivo, non è necessario l'orchestrator, poiché ViewModel fornirà a View il modo di capire quando aggiornarsi. Questo è il motivo per cui le "notifiche" in questo diagramma usano la linea "squigly" e non la linea diretta. Significa che View osserva le modifiche in ViewModel, non che ViewModel dipende da View.

La cosa più importante che dovresti prendere dall'architettura pulita di Martin non è il design stesso, ma il modo in cui gestisci le dipendenze. Uno dei punti critici che sottolinea nei suoi discorsi è che quando c'è un confine, allora tutte le dipendenze del codice che attraversano quel confine lo attraversano in una sola direzione. Nel diagramma, questo confine è rappresentato da una doppia linea. E c'è un sacco di inversione di dipendenza attraverso interfacce ( InputBoundary, OutputBoundarye DataAccessInterface) che fissa la direzione codice dipendenza.

Al contrario, ViewModelin Clean Architecture è semplicemente DTO senza logica. Ciò è reso evidente dal <DS>tag. E questo è il motivo per cui orchestratorè necessario, poiché Viewnon saprà quando eseguirne la logica.

Se dovessi "appiattire" il diagramma su come apparirà durante il runtime, sarà simile a questo:

Quindi, durante il runtime, le dipendenze sono nella direzione "sbagliata", ma va bene.

Consiglio di guardare i suoi discorsi su Clean Architecture per capire meglio il suo ragionamento.