Arquitectura limpia: ¿Qué es el modelo de vista?

En su libro 'Arquitectura limpia', el tío Bob dice que el presentador debe poner los datos que recibe en algo que él llama 'Ver modelo'.

¿Es esto lo mismo que el 'ViewModel' del modelo de diseño Model-View-ViewModel (MVVM) o es un simple Objeto de transferencia de datos (DTO)?

Si es no un simple DTO, cómo se relaciona a la vista? ¿La vista recibe actualizaciones a través de una relación de observador?

Supongo que se parece más al ViewModel de MVVM, porque en el Capítulo 23 de su libro, Robert Martin dice:

El trabajo de [El presentador] es aceptar los datos de la aplicación y formatearlos para la presentación de modo que la Vista pueda simplemente moverlos a la pantalla. Por ejemplo, si la aplicación desea que se muestre una fecha en un campo, le dará al Presentador un objeto Fecha. El presentador formateará esos datos en una cadena apropiada y los colocará en una estructura de datos simple llamada modelo de vista, donde la vista puede encontrarlos.

Esto implica que la Vista está conectada de alguna manera al ViewModel, en lugar de simplemente recibirla como un argumento de función, por ejemplo (como sería el caso con un DTO).

Otra razón por la que creo que esto se debe a que si observa la imagen, el Presentador usa el Modelo de vista, pero no la Vista. Mientras que los usos del presentador tanto la salida de Límites y la salida de datos DTO.

Si no es un DTO ni el ViewModel de MVVM, explique qué es.

¿Es esto lo mismo que el 'ViewModel' del patrón de diseño Model-View-ViewModel (MVVM)

No

Eso sería esto :

Eso tiene ciclos. El tío Bob ha estado evitando cuidadosamente los ciclos .

En cambio tienes esto:

Que ciertamente no tiene ciclos. Pero te deja preguntándote cómo sabe la vista sobre una actualización. Llegaremos a eso en un momento.

o es un simple objeto de transferencia de datos (DTO)?

Para citar a Bob de la página anterior:

Puede usar estructuras básicas u objetos simples de transferencia de datos si lo desea. O puede empaquetarlo en un hashmap o construirlo en un objeto.

Arquitectura limpia p207

Entonces, claro, si quieres.

Pero sospecho fuertemente que lo que realmente te está molestando es esto :

Este pequeño y lindo abuso de UML contrasta la dirección de la dependencia del código fuente con la dirección del flujo de control. Aquí es donde se puede encontrar la respuesta a su pregunta.

En una relación de uso:

el flujo de control va en la misma dirección que la dependencia del código fuente.

En una relación de implementación:

El flujo de control generalmente va en la dirección opuesta a la dependencia del código fuente.

Lo que significa que realmente estás viendo esto:

Debería poder ver que el flujo de control nunca va a llegar del Presentador a la Vista.

¿Como puede ser? Qué significa eso?

Significa que la vista tiene su propio hilo (que no es tan inusual) o (como señala @Euphoric) el flujo de control está llegando a la vista desde otra cosa que no se muestra aquí.

Si es el mismo hilo, entonces la Vista sabrá cuándo el Modelo de Vista está listo para ser leído. Pero si ese es el caso y la vista es una GUI, tendrá dificultades para volver a pintar la pantalla cuando el usuario la mueva mientras espera la base de datos.

Si la vista tiene su propio hilo, entonces tiene su propio flujo de control. Eso significa que para implementar esto, la vista tendrá que sondear el modelo de vista para notar los cambios.

Como el Presentador no sabe que existe la Vista y la Vista no sabe que existe el Presentador, no pueden llamarse entre sí. No pueden lanzar eventos entre ellos. Todo lo que puede suceder es que el presentador escribirá en el modelo de vista y la vista leerá el modelo de vista. Siempre que lo desee.

Según este diagrama, lo único que comparten la Vista y el Presentador es el conocimiento del Modelo de vista. Y es solo una estructura de datos. Así que no esperes que tenga ningún comportamiento.

Esto puede parecer imposible, pero puede hacerse funcionar incluso si View-Model es complejo. Un pequeño campo actualizado es todo lo que la vista tendría que sondear para detectar un cambio.

Ahora, por supuesto, puede insistir en usar el patrón de observador, o hacer que algo del marco le oculte este problema, pero comprenda que no tiene que hacerlo.

Aquí hay un poco de diversión que ilustraba el flujo de control:

Tenga en cuenta que cada vez que ve que el flujo va en contra de las direcciones que definí antes, lo que está viendo es una llamada que regresa. Ese truco no nos ayudará a llegar a la Vista. Bueno, a menos que primero regresemos a lo que se llama Controlador. O simplemente podría cambiar el diseño para poder acceder a la vista. Eso también soluciona lo que parece el comienzo de un problema de yoyo con el acceso a datos y su interfaz.

La única otra cosa que aprender aquí además de eso es que Use Case Interactor puede llamar a las cosas en el orden que quiera, siempre que llame al presentador en último lugar.

Encuentro este problema demasiado confuso y tomaría mucho texto y tiempo explicarlo adecuadamente, ya que creo que no entiendes tanto Martin's Clean Architecture como MVVM.

Lo primero que debe tener en cuenta es que el diagrama que publicó está incompleto. Solo muestra "lógica de negocios", pero le falta algún tipo de "orquestador" que realmente haga que las partes se muevan en el orden correcto.

El código del orquestador sería tan simple como

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

Creo que escuché a Martin hablar de esto en una de sus charlas sobre Arquitectura limpia.

Otra cosa a destacar es que el comentario de candied_orange sobre la falta de ciclos es incorrecto. Sí, los ciclos no existen (y no deberían) en la arquitectura del código. Pero los ciclos entre instancias de tiempo de ejecución son comunes y a menudo conducen a un diseño más simple.

Ese es el caso en MVVM. En MVVM View depende de ViewModel, y ViewModel usa eventos para notificar a View sobre sus cambios. Esto significa que en el diseño de las clases, solo hay dependencia de las clases View a Model, pero durante el tiempo de ejecución, hay una dependencia cíclica entre las instancias View y ViewModel. Debido a esto, no hay necesidad de orquestador, ya que ViewModel proporcionará una forma de Ver para averiguar cuándo actualizarse. Esta es la razón por la cual las "notificaciones" en este diagrama usan la línea "squigly" y no la línea directa. Significa que View observa los cambios en ViewModel, no que ViewModel dependa de View.

Lo más importante que debe tomar de la arquitectura limpia de Martin no es el diseño en sí, sino cómo maneja las dependencias. Uno de los puntos críticos que señala en sus conversaciones es que cuando hay un límite, todas las dependencias de código que cruzan ese límite lo cruzan en una sola dirección. En el diagrama, este límite está representado por una doble línea. Y hay mucha inversión de dependencia a través de interfaces ( InputBoundary, OutputBoundaryy DataAccessInterface) que corrige la dirección de dependencia del código.

Por el contrario, ViewModelen Clean Architecture es simplemente DTO sin lógica. Esto se hace obvio por <DS>etiqueta. Y esta es la razón por la cual orchestratores necesario, ya Viewque no sabrá cuándo ejecutar su lógica.

Si tuviera que "aplanar" el diagrama en cómo se verá durante el tiempo de ejecución, se vería así:

Entonces, durante el tiempo de ejecución, las dependencias están en la dirección "incorrecta", pero eso está bien.

Recomiendo ver su charla sobre Arquitectura limpia para comprender mejor su razonamiento.