Maui: MVU podría no ser lo que crees que es

Gracias @aspnetde , espero que se una a nosotros mientras trabajamos en la implementación de esta idea durante los próximos 18 meses más o menos. Dada su historia con MVU, espero que tenga mucho para contribuir.

Creo que es demasiado pronto para decir que .NET MAUI es o no MVU, ya que aún no lo hemos construido . :)

Sí, tenemos un prototipo. Sí, está inspirado en el experimento Comet. Y sí, sabemos que existe la preocupación de que lo que hemos mostrado hasta ahora no coincide con la definición de MVU de todos.

Mi esperanza es que podamos colaborar! Si lo que terminamos diseñando y enviando merece una etiqueta diferente, estoy de acuerdo en que deberíamos darle una.

¿Cómo esperaría ver C# MVU en .NET MAUI?

¿Qué nuevas características del idioma cree que son necesarias, si es que las hay?

¿Podríamos/deberíamos considerar la integración de Fabulous y/o qué patrones tiene sentido hacer comunes entre C# y F#, y qué debería ser diferente?

¿Cómo esperaría ver C# MVU en .NET MAUI?

¿Alguna vez has escuchado a alguien decir C# MVC o C# MVVM? _Model-View-Update_ también conocido como _The Elm Architecture_ es un patrón arquitectónico bien definido, no una implementación dependiente del lenguaje.

¿Qué nuevas características del idioma cree que son necesarias, si es que las hay?

• Si bien los tipos de unión ayudarían a simplificar la definición de mensajes de forma masiva, eso se puede hacer a través de interfaces/clases abstractas y una subclase por mensaje, aunque eso requiere un poco más de código repetitivo para escribir.
• Para procesar mensajes, la coincidencia de patrones es útil si no es necesaria. Creo que el estado actual de las expresiones de cambio de C# ya es lo suficientemente bueno para eso, ya que la forma de los mensajes será simple.
• Por último, pero no menos importante, la característica más importante que veo es la inmutabilidad por defecto y las comparaciones de igualdad estructural habilitadas. Por lo que recuerdo, la propuesta actual de registros en C# 9 (también conocidas como clases de datos), ofrecerá exactamente eso.

Por lo tanto, C# 9, si bien sigue siendo más ruidoso que F#, estaría bien desde mi punto de vista actual.

¿Podríamos/deberíamos considerar la integración de Fabulous y/o qué patrones tiene sentido hacer comunes entre C# y F#, y qué debería ser diferente?

Como se escribió anteriormente, no debe haber nada particularmente específico del idioma en el enfoque general, ya que MVU en sí es solo el estilo arquitectónico o el modelo de aplicación como lo llama.

@TimLariviere Ha hecho algunas propuestas para hacer avanzar a Fabulous recientemente, que también incluye ideas sobre un DSL más similar a SwiftUI. Es posible que también desee echar un vistazo y/o participar allí.

Por cierto: hice una comparación 1:1 de XF + C# + MVVM y XF + F# + MVU el año pasado, los resultados se pueden encontrar aquí , incluido el código fuente.

Creo que es demasiado pronto para decir que .NET MAUI es o no es MVU

No se trata de si MAUI será MVU al final. Se trata de la muestra en el blog de anuncios que ya generó tanta confusión en la comunidad. Básicamente, debo suponer que los autores aún no investigaron MVU. Hablar de "C# MVU" no mejora esto.

Estoy de acuerdo con @aspnetde y @forki, el problema aquí radica en la comunicación.

Creo que ninguno de nosotros está discutiendo si descartamos o cambiamos el C# DSL inspirado en el cometa por MAUI/XF, pero incluso si tomamos lo que se ha hecho hasta ahora con él, esto todavía está usando el concepto de enlace subrayado que es parte del patrón MVVM .

Esto es algo que he estado preguntando una y otra vez en la comunicación directa y también en los problemas, tal vez sea una buena idea que todos los involucrados lean diferentes patrones como MVVM y MVU.

Dicho esto, incluso hay una forma de implementar MVU sobre MVVM, pero la pregunta sigue siendo qué problema resolvería.

¿Alguna vez has escuchado a alguien decir C# MVC o C# MVVM?

Sí, entiendo que es extraño decir C# o XAML seguido de un patrón arquitectónico como MVVM o MVU. Entre la comunidad más amplia de desarrolladores con los que hablo, existe la necesidad de dejar en claro que puede utilizar cualquier cantidad de combinaciones dentro de su proyecto. La intención no es decir que una "MVVM de C#" sea diferente desde el punto de vista arquitectónico a una "MVVM de XAML", sino que la combinación es posible y, por lo tanto, la experiencia del desarrollador en su conjunto es ligeramente diferente.

Pensé que este hilo podría discutir cómo se vería MVU en .NET MAUI, pero quizás la discusión más productiva aquí es cómo hablamos sobre múltiples experiencias de desarrollador y patrones de arquitectura dentro de un solo producto.

Parece que esa es la dirección de la mayoría de los comentarios aquí, queriendo discutir cómo llamamos y etiquetamos las cosas y cómo usamos los términos. Me encantaría su opinión sobre esto, ya que hago gran parte de la comunicación y quiero asegurarme de que estoy agregando claridad y no generando confusión.

Se trata de la muestra en el blog de anuncios que ya generó tanta confusión en la comunidad.

Esa fue mi contribución al blog y me disculpo por la confusión que les generó. Calculé mal que al agregar enlaces al blog de Elm y

Básicamente, debo suponer que los autores aún no investigaron MVU.

Hemos tenido una extensa conversación y debate sobre el tema. Por favor, no asuma, y ​​trataré de no hacerlo también.

la pregunta sigue siendo qué problema resolvería.

@dersia, el problema general a resolver es dar opciones a los desarrolladores. Si está preguntando qué resuelve MVU además de MVVM, no tengo idea: esto no es algo que se solicite o algo que estemos tratando de hacer.

La refactorización propuesta en los puntos n.º 28 y n.º 66 se trata parcialmente de separar el enlace de datos y las cosas específicas de MVVM de las implementaciones del renderizador, de modo que si opta por MVU, no tendrá funciones adicionales utilizadas en MVVM.

No anticipé cuánto peso soportaría el fragmento de código

Pero esa es la carne, ¿verdad? Y lo siento, no coincidía con la etiqueta.

@davidortinau

Parece que esa es la dirección de la mayoría de los comentarios aquí, queriendo discutir cómo llamamos y etiquetamos las cosas y cómo usamos los términos. Me encantaría su opinión sobre esto, ya que hago gran parte de la comunicación y quiero asegurarme de que estoy agregando claridad y no generando confusión.

No estoy seguro de lo que queda por agregar de mi parte. Creo que expresé mi posición alto y claro :-). Si va a implementar MVU, empujará una puerta abierta. Si es lo que se puede suponer al mirar el fragmento en la publicación del anuncio y el repositorio de Comet, siéntase libre de hacerlo, pero _por favor_ deje de llamarlo MVU.

Gracias.

Como se mencionó a Don en este hilo :-) - CC: @dsyme

No entiendo por qué esto se llama MVU, cuando no lo es. Podría ser un gran paradigma y funcionar muy bien aquí. ¿Por qué no proponer un término adecuado que se ajuste al paradigma y no confunda?

@aspnetde que queda de tu lado? Mucho supongo :).
Leí algunas partes de su tesis. Tengo que decir que me gustó. También leí el libro de Don Syme sobre F#. Me gusta la programación funcional. Según mi experiencia, es conciso, pero difícil de comprender (comprender). La legibilidad es una parte muy importante del ciclo de vida del desarrollo. Gran parte del tiempo se dedica a leer código. Y la recursividad es solo de escritura. Puede escribirlo una vez, pero casi nadie puede leerlo (de manera similar a las expresiones regulares).
En el pasado, probé Redux con Angular durante mi tiempo de creación de prototipos/investigación en la empresa. ¿Es un enfoque medio élfico? Fue una experiencia valiosa. Aprendí que tengo que tener cuidado de no mutar el estado y, como resultado, no tendré que recordar toda la pila, donde exactamente el estado puede cambiar repentinamente.
Entiendo los beneficios de la inmutabilidad, pero vi una presentación con Erik Meijer, quien de repente destrozó la cabeza de un oso de peluche para mostrarnos que el mundo real es mutable.

Entonces, lo que me gustaría señalar: ¿No está nuestro pensamiento natural en contra de estos paradigmas? ¿Cuál es tu experiencia?

Tengo mucha experiencia con XAML/C#/MVVM, así que me pregunto por qué Don Syme considera que XAML es innecesario.
Desde mi experiencia, ayuda a separar las preocupaciones (interfaz de usuario, presentación, lógica comercial, etc.). No estoy muy seguro de si estos DSL (marcas de C#) y MVU ayudan a mejorar la calidad del código a largo plazo. Los desarrolladores sin experiencia o que no se preocupan mezclarán las responsabilidades. También necesito más experiencia con el patrón MVU para entenderlo correctamente, pero probaste ambos paradigmas y es muy valioso para toda la comunidad.
Por favor comparte todo lo que puedas. Gracias @aspnetde!

Muchas gracias (a todos) por su comprensión.

@davidortinau tal vez hubo un malentendido aquí, estoy totalmente a favor de la elección y dejo que todos elijan por sí mismos qué patrón/paradigma usar. Solo estaba tratando de decir que deberíamos nombrar las cosas correctamente. Como todos en el desarrollo de software saben, nombrar cosas es una de las cosas más difíciles de hacer, pero si ya hay cosas bien definidas nombradas, no deberíamos comenzar a reutilizar esos nombres para cosas que no son.

Señorita comunicación La falta de
En este caso, creo que se debe corregir el uso de una redacción incorrecta y, para que eso suceda, me encantaría que este proyecto
a) entender que MVU es el nombre equivocado para lo que estamos hablando aquí
y b) encontrar el término adecuado para describir lo que estamos tratando de establecer aquí
y luego c) actualice a todos y comience a usar ese nuevo nombre

Creo que todavía estamos en un punto en el que aún podemos regresar y arreglarlo. Hagámoslo bien, lo peor que podría pasar es que la comunidad XF/Maui entienda a MVU como algo más que el resto del mundo.

Dicho esto, soy un gran admirador de MVU y también me encanta MVVM, y creo que el enfoque fluido de MVVM (todavía no tengo un nombre mejor) como en Comet y lo que se ha presentado hasta ahora es excelente y ayuda a un muchos desarrolladores y lo apoyaré, solo creo que deberíamos arreglar el nombre.

Editar: Miss Communication abandonó el concurso.

Entiendo los beneficios de la inmutabilidad, pero vi una presentación con Erik Meijer, quien de repente destrozó la cabeza de un oso de peluche para mostrarnos que el mundo real es mutable.

@tomasfabian esto está mal.

Tienes que empezar a ver el mundo como una serie de eventos, eso es lo que realmente es (no, no quiero comenzar una discusión sobre el abastecimiento de eventos aquí).
Lo que le paso al oso de peluche es solo que se le agrego un nuevo evento a su estado, el evento en este caso es "arrancado de cabeza". Y como puede darse cuenta una vez que sucedió un evento, no puede revertirlo, ya que no puede simplemente deshacer o eliminar lo que sucede. Para volver a colocar la cabeza en el osito, necesitaría un nuevo evento llamado "cabeza cosida de nuevo en el cuerpo". 😉

Discutir los beneficios o no de FP y MVU está fuera de tema aquí en mi humilde opinión. Este problema era, pensé, solo sobre el potencial de falta de comunicación y nombres precisos.

@isaacabraham tal vez tengas razón y te pido disculpas por ello. Es mi culpa. Sé que nombrar las cosas es importante, pero por otro lado el título del problema es "MVU podría no ser lo que crees que es". Así que es de esperar que sea un tema un poco más amplio que nombrar cosas.
gracias, tomas

@tomasfabian Estaría súper feliz de conversar contigo sobre los pros y los contras de MVU, FP o lo que sea, real o imaginario 😊 Simplemente no creas que este es el foro apropiado para eso.

@davidortinau
En cuanto a qué características del lenguaje y cambios en la arquitectura serían útiles, espero poder contribuir con algunas sugerencias:

* La palabra clave new y otros ruidos sintácticos.
A diferencia de Dart o Kotlin, es probable que C# se quede con una palabra clave requerida new para siempre, ya que hacerla opcional es un cambio importante y una propuesta impopular, incluso como una directiva de suscripción por archivo. Entonces, en lugar de eso, tal vez una clase estática oficial (y mantenida) (o una clase estática por espacio de nombres de vista MAUI) que contenga métodos estáticos que simplemente envuelvan constructores e inicialicen cualquier propiedad de solo inicio, si corresponde, al menos para el conjunto central de Objetos de vista MAUI. Luego podemos poner una directiva using static en la parte superior de nuestros archivos .cs de código de vista y luego llamar a los métodos sin el ruido sintáctico de new . Esto reduciría un poco el desorden y el ruido de las funciones de vista de C#. Por supuesto, la comunidad podría generar automáticamente estos contenedores de constructores de métodos estáticos (he hecho algo similar para Xamarin.Forms para usar con CSharpForMarkup), pero sería bueno tener un conjunto de ellos en el cuadro mantenido por El proyecto MAUI.

Además, cualquier propuesta de lenguaje C# que ayudaría a reducir el desorden sintáctico o el ruido en los árboles de expresión grandes (como es común en las funciones de vista de MVU/Comet/CSharpForMarkup) sería de gran ayuda. C # 9 ha recorrido un largo camino en este sentido para mejorar las partes M y U de MVU, pero la parte V sigue siendo un punto débil en cuanto a la sintaxis.

* Propiedades de extensión *
Sé que la propuesta de "extensión de todo" está suspendida por ahora, pero una cosa que podría ser útil para MVVM con marcado C# (por ejemplo, CSharpForMarkup con Xamarin.Forms), serían las propiedades de extensión. Con CSharpForMarkup, cada ayudante tuvo que implementarse mediante un método de extensión, pero en algunos casos, una propiedad de extensión (que se puede usar en el inicializador del objeto) se vería mucho mejor:

// Instead of this:
public View Body() =>
    new Widget() {
        BuiltInProperty = "initial value",
    }.SetExtensionProperty("initial value");

// the extension property could be included in the object initializer:
public View Body() ->
    new Widget() {
        BuiltInProperty = "initial value",
        ExtensionProperty = "initial value",
    };

Esto solo se aplica realmente a los árboles de objetos de vista mutables, como en MVVM con C# para el marcado. Para MVU u otras arquitecturas de interfaz de usuario funcional, esto no es aplicable ya que los objetos de vista son inmutables. En esos casos, un método de extensión fluida es aún más apropiado.

* Sea menos obstinado (o de bajo nivel si lo prefiere) sobre la gestión estatal *
Creo que una de las mayores barreras de entrada para implementar MVU sobre Xamarin.Forms fue la falta de dos componentes esenciales: el gráfico de objetos livianos que las funciones de vista podrían devolver, que el marco podría "representar" en componentes reales (con su representaciones específicas de la plataforma, etc...). Y la segunda pieza es un motor de diferenciación que actualiza eficientemente las vistas específicas de la plataforma de peso pesado al buscar diferencias entre un valor de retorno de una función de vista y otra, incluida una forma de hacer diferencias de manera eficiente al hacer diferencias parciales, etc.

Parece que MAUI ahora proporciona esas dos piezas esenciales, ¡lo cual es genial! Sin embargo, al menos en la superficie parece estar muy relacionado con una forma obstinada de administrar el estado que algunos en la comunidad de MVU dirían que está más cerca de MVVM que de MVU o arquitecturas de interfaz de usuario "funcionales" similares. Creo que preferiría mantener las dos piezas esenciales que mencioné anteriormente (gráfico de objeto de vista liviano y motor de diferenciación eficiente) y combinarlo con un sistema de componentes de nivel inferior sobre el que MVU o Comet podrían superponerse de manera eficiente, según el desarrollador. elección. ¿Quizás ese ya es el objetivo, y no lo estoy viendo? Si es así, me encantaría ver más discusión al respecto con al menos algunos ejemplos básicos.

@aspnetde ¿ borraste tu publicación?

@tomasfabian

Según mi experiencia, [MVVM] ayuda a separar las preocupaciones (interfaz de usuario, presentación, lógica comercial, etc.)

Sí, lo hace. He tenido algunas buenas experiencias con grandes aplicaciones Xamarin.iOS y Xamarin.Android creadas con MvvmCross. Aunque hoy en día prefiero mucho más las bibliotecas a los marcos, creo que todos esos proyectos (algunos con LOC de seis cifras) han sido un éxito, tanto desde el punto de vista técnico como empresarial.

Creo que MVVM especialmente hace un buen trabajo cuando se trata de escalar una aplicación. Especialmente en dispositivos móviles, donde nos vemos obligados a enviar monolitos, nos ayudó a refactorizar nuestras aplicaciones en módulos independientes después de que superaron cierto tamaño.

¿No está nuestro pensamiento natural en contra de estos paradigmas ([MVU])? ¿Cuál es tu experiencia?

No lo creo. Tome su experiencia con Redux para el almacenamiento e imagine toda su aplicación para beneficiarse de sus ventajas. Si bien parece ser más complejo a primera vista, en mi experiencia es mucho más simple de entender y trabajar con él. Como suele señalar @forki , es casi aburrido porque el flujo de datos unidireccional deja en claro lo que sucede todo el tiempo.

No estoy muy seguro de si estos DSL (marcas de C#) y MVU ayudan a mejorar la calidad del código a largo plazo.

Si bien tanto MVU como MVVM tienen diferentes ventajas, ambos también tienen diferentes inconvenientes.

A pesar de considerar que nuestros proyectos MVVM fueron exitosos, mi equipo y yo perdimos algo de cabello al depurarlos. En un proyecto en particular, comenzamos a sufrir por la complejidad causada por la falta de experiencia de los nuevos miembros del equipo y los malentendidos, como ya lo señaló. Creo que es menos probable en MVU cuando se aplica estrictamente, porque define los límites de cómo funcionan las cosas de manera tan estrecha que es casi más difícil salir de eso y construir las cosas de manera incorrecta, que al revés.

Para MVU veo dos problemas principales. Primero: Escalado. Muchos abogan por un solo programa. Soy escéptico aquí (y creo que múltiples programas/módulos serían una mejor manera). Segundo: en este momento, una cosa como Fabulous se encuentra encima de Xamarin.Forms. Así que es una capa de abstracción encima de una capa de abstracción encima de una capa de abstracción encima de iOS/Android. Esa es una gran cantidad de complejidad. Por lo tanto, no solo se trata de errores sin resolver que a nadie le importan, sino que también es un trabajo más o menos tedioso y desagradable actualizar una capa de abstracción (Fabulous) cuando cambia la otra (Xamarin.Forms).

Ahí es donde vería una gran oportunidad para MAUI. Honestamente, me encantaría ver a los mantenedores de Fabulous unir fuerzas con Microsoft aquí. Y realmente espero que Microsoft no lo arruine, como lo han hecho otras partes de la organización en el pasado.

Tomás

Cuando estaba leyendo el anuncio oficial el otro día, me sorprendió lo que allí se presentaba como MVU:

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

En lo que a mí respecta, esto no es MVU . Ya escribí algunos pensamientos sobre por qué pienso eso aquí .

Don Syme, quien, según tengo entendido, pasó varios meses de 2018 implementando MVU sobre Xamarin.Forms y construyendo lo que luego se convirtió en Fabulous , es un poco más diplomático , pero el resultado final es el mismo.

Entonces, ¿cuál es mi punto?

• Me encantaría que implementaras el patrón arquitectónico real, sin importar si es en C# o F#. Llegar a las personas detrás de Fabulous podría ser un comienzo aquí.
• Si no está interesado en eso pero tiene una visión clara sobre cómo construir sobre lo que está disponible hoy como la biblioteca Comet , entonces considere usar un nombre más apropiado para ese "modelo de aplicación". Inventa algo nuevo. Nómbrelo MSMVU. Lo que. Pero no vendas manzanas por naranjas.

¡Salud!

¿Por qué lo nombrarían MSMVU? Comet ha sido MVU y seguirá siéndolo. Y Maui es una MVU.

Creo que es demasiado pronto para decir que .NET MAUI es o no es MVU

No se trata de si MAUI será MVU al final. Se trata de la muestra en el blog de anuncios que ya generó tanta confusión en la comunidad. Básicamente, debo suponer que los autores aún no investigaron MVU. Hablar de "C# MVU" no mejora esto.

No genera confusión alguna. Es solo que algunas personas no pueden manejarlo al ver C # haciendo MVU.

Por lo que vale, SwiftUI (del que Comet se inspira la mayor parte) tiende a llamar a su patrón MVVM, aunque no hay pautas explícitas.
Sin embargo, no he encontrado ninguna mención de MVU.

@TimLariviere https://github.com/Clancey/Comet#key -conceptos
Básicamente, Comet lo llamó MVU y ya perdió el punto del bucle de mensajes que tenemos en las definiciones anteriores de MVU.

Por lo que vale, SwiftUI (del que Comet se inspira la mayor parte) tiende a llamar a su patrón MVVM, aunque no hay pautas explícitas.

Ni siquiera está mal, mirando el ejemplo al comienzo de esta publicación aquí: https://nalexn.github.io/clean-architecture-swiftui/

Sin embargo, no he encontrado ninguna mención de MVU.

La misma publicación también lo analiza brevemente (como una combinación de SwiftUI + Redux = TEA). Aunque luego se está dando un giro extraño a la "Arquitectura Limpia" 😄

Ya que me han mencionado aquí, solo diré algunas cosas.

• Creo que MAUI es excelente y creo que aprender sobre MVU como arquitectura puede ser útil para que las personas entiendan MAUI.

• Es fácil obsesionarse con las palabras, y probablemente todos deberíamos tomar un respiro y tratar de no preocuparnos por eso en esta etapa, ya que hay mucho tiempo para ajustar las palabras que se usan y creo que el mensaje sobre la terminología precisa ha sido Escuchó. Personalmente, creo que Elm ha establecido que el uso sin adornos y sin reservas de "MVU" significa mensajes explícitos, actualización explícita, modelos funcionales, recálculo de vista funcional y actualización diferencial. Pero hay muchas variaciones de MVU y MAUI es un punto en ese espectro (que cubre todo el camino hasta MVVM como una especie de sistema de procesamiento de mensajes incremental manualmente con un estado mutable omnipresente e implícito). La comunicación SwiftUI es interesante desde esta perspectiva.

• Me doy cuenta de que las personas tienden a tener creencias y opiniones muy fuertes en esta área y pueden tomar las cosas de manera bastante personal. Sé cómo es eso y, al igual que el diseño de lenguajes de programación, creo que todos los puntos del espacio tienen pros y contras. Animo a todos a que prueben, usen, aprendan, compartan y trabajen juntos para crear la mejor gama de tecnologías posible.

@dsyme
Creo que el término adecuado para la arquitectura Comet/MAUI es una variación del flujo de datos unidireccional (o UDF), pero no MVU, ya que MVU es en sí mismo una variación muy específica de UDF. MAUI/Comet ciertamente califica como un marco UDF (al igual que SwiftUI), pero no califica como un marco MVU. Hay varias variaciones de UDF que incluyen MVU, Flux, Redux, React, etc... pero es un error de comunicación llamar a Comet MVU cuando no es en absoluto MVU.

A diferencia de MVU, el modelo es mutable y se modifica mediante código en la función Ver. Luego se observan las mutaciones y las vistas reaccionan a esas mutaciones volviendo a renderizar. Todavía es unidireccional porque las vistas no están mutadas, pero no hay una función de actualización, ni mensajes, ni envío de mensajes, por lo tanto, no MVU. Está más cerca de una variación unidireccional de MVVM.

@JeroMiya Gracias, ¿tiene una referencia para esa terminología?

@dsyme No tengo una referencia específica para ello, pero comencé a escuchar que el término se usaba en los primeros días de React, específicamente en referencia a React en sí mismo y algunos de los primeros patrones que surgieron, como Redux y Flux. Recuerdo un artículo que describía una serie de variantes de UDF (principalmente en el espacio React), pero no puedo encontrarlo ahora.

Dicho esto, no es una arquitectura formal, más como el concepto básico de que la vista es una función del modelo, en lugar de que la vista sea un árbol de objetos con estado que muta en respuesta a los eventos. El concepto de UDF no especifica necesariamente cómo se actualiza el modelo o si es mutable o inmutable. MVU amplía el concepto de UDF no solo a la vista en sí, sino también al proceso de actualización del modelo. Entonces, en MVU, el modelo también es inmutable, y los cambios de estado de la interfaz de usuario se representan como comandos que producen nuevos modelos, que desencadenan nuevas vistas.

Por supuesto, no es un concepto nuevo, incluso antes de React, la mayoría de los marcos web del lado del servidor como Asp.Net MVC, Rails e incluso PHP cuentan técnicamente como unidireccionales. Simplemente no era común para los principales marcos de SPA y los marcos de interfaz de usuario del lado del cliente antes de que apareciera React.

@dsyme No tengo una referencia específica para ello, pero comencé a escuchar que el término se usaba en los primeros días de React, específicamente en referencia a React en sí mismo y algunos de los primeros patrones que surgieron, como Redux y Flux. Recuerdo un artículo que describía una serie de variantes de UDF (principalmente en el espacio React), pero no puedo encontrarlo ahora.

Dicho esto, no es una arquitectura formal, más como el concepto básico de que la vista es una función del modelo, en lugar de que la vista sea un árbol de objetos con estado que muta en respuesta a los eventos. El concepto de UDF no especifica necesariamente cómo se actualiza el modelo o si es mutable o inmutable. MVU amplía el concepto de UDF no solo a la vista en sí, sino también al proceso de actualización del modelo. Entonces, en MVU, el modelo también es inmutable, y los cambios de estado de la interfaz de usuario se representan como comandos que producen nuevos modelos, que desencadenan nuevas vistas.

Por supuesto, no es un concepto nuevo, incluso antes de React, la mayoría de los marcos web del lado del servidor como Asp.Net MVC, Rails e incluso PHP cuentan técnicamente como unidireccionales. Simplemente no era común para los principales marcos de SPA y los marcos de interfaz de usuario del lado del cliente antes de que apareciera React.

@JeroMiya gracias por esto, así es exactamente como entiendo MVU.
Incluso diría que una de las aplicaciones más antiguas y aún más utilizadas que usa y ejemplifica MVU en su mejor forma es MS Excel.

@dsyme al leer sus comentarios, tengo la sensación de que se refiere a MAUI como el término para la arquitectura discutida (CSharpForMarkup con MVVM).
Por favor, clarifícame que esto no es lo que entiendes que es MAUI o si lo es.
Según tengo entendido, MAUI es solo el próximo MS Application Framework para reemplazar a XF en algún momento en el futuro.

Realmente me gusta la forma en que va este tema y sus comentarios. Gracias por todos los participantes. Tal vez juntos podamos establecer todas las diferentes arquitecturas como sabores posibles para MAUI y nombrarlos correctamente.

@dersia ¡ Gracias! Solo una nota de mi propia experiencia con CSharpForMarkup: es un nivel un poco más bajo que MVVM, más un conjunto de métodos de extensión y utilidades para hacer que el marcado de C# sea más ágil y atractivo. Ciertamente, puede implementar un patrón MVVM con él, ya que tiene ayudantes para facilitar los enlaces de ViewModel, pero lo que terminé haciendo fue implementar toda mi lógica de vista en Redux en lugar de ViewModels. Solo necesitaba agregar algunos métodos de extensión para vincular las propiedades de vista a los selectores de estado, que son solo Func<StateType, ChildStateType> que paso a los operadores Select y DistinctUntilChanged en la tienda de estado de Redux, que es un Observable<StateType> . No es un flujo de datos unidireccional, pero no tenía una forma madura de hacer diferencias de árbol de objetos de interfaz de usuario y ver funciones como lo hace Fabulous ahora.

Hace algún tiempo, la policía de REST intentó meternos en la garganta que todos nosotros no deberíamos llamarnos REST. Todo el mundo todavía lo llama DESCANSO hoy y todos estamos vivos y bien. 😉

@bitbonk, la comunidad REST abandonó el término porque se volvió cada vez más inútil a medida que se

@davidortinau @tomasfabian , todavía tengo que ver un ejemplo de MVU en MAUI. Intentaré resolver un ejemplo esta noche. Acabo de hacer algo similar para WinForms aquí . Supongo que no debería ser demasiado difícil.

@JeroMiya Gracias, ¿tiene una referencia para esa terminología?

@dsyme , creo que se originó con React Flux, pero señalaron arquitecturas de juegos, es decir, Doom 3. Creo recordar haber discutido esto con @TIHan cuando se presentó por primera vez.

• https://reactjs.org/blog/2014/05/06/flujo.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/unidireccional-flujo-de-datos

Aquí está mi intento de un ejemplo de C#. No tengo MAUI disponible para probar esto como un ejemplo real. No hay vista previa, ¿verdad? De todos modos, esta es una traducción aproximada de la idea.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Una vez probé brevemente

Soy relativamente nuevo en MVU y probablemente tenga muy poca experiencia usándolo en comparación con muchos de ustedes. Pero los conceptos de MVU definitivamente han captado mi interés y lo estoy disfrutando. Estoy muy contento de ver que los desarrolladores de C# reciben un marco para ayudar a desarrollar en el patrón MVU.

Estoy totalmente de acuerdo en que MAUI MVU no es la típica MVU y tiene una gran influencia de SwiftUI. Su principal autor, el mismo Clancey, lo había dejado muy claro en casi todas sus sesiones. Todos sabemos que Redux está muy influenciado por MVU, al igual que SwiftUI, Flutter y muchos otros marcos. Ninguno de ellos es MVU puro.

Pero estoy seguro de que todos estamos de acuerdo en que el patrón arquitectónico más cercano para todos estos marcos es MVU. Esa es la razón por la cual la gente lo refiere. Y recuerde que estamos hablando de un título de blog para un marco que se lanzará dentro de un año y medio.

Y si dices que la gente se enoja por el título de este blog. No creo que debamos preocuparnos por ellos. La comunidad aún necesita seguir adelante. Gastemos nuestra energía para mejorar este marco. No te preocupes demasiado por los pequeños detalles.

Pero estoy seguro de que todos estamos de acuerdo en que el patrón arquitectónico más cercano para todos estos marcos es MVU. Esa es la razón por la cual la gente lo refiere.

Perros, caballos, gatos y chimpancés están muy cerca unos de otros. De ahora en adelante me referiré a todos ellos como gatos.

:) Bueno, no tienes que hacerlo. Pero déjame decirte algo: los gatos, tigres, leopardos, etc. se llaman gatos. Y me alegro de que lo hayas mencionado. Porque ese es exactamente el caso aquí.

@aspnetde : Thomas, con todo lo dicho. Debo decir que su blog original de MVU es uno de los mejores artículos que explica el concepto de manera muy clara y precisa. He aprendido bastante de eso. Gracias

@ libin85 ahí está exactamente el problema. Comenzaste a enumerar cosas que en realidad están en una categoría e ignoraste las que no lo están. Al poner la muestra de MAUI en la categoría MVU, básicamente pones un chimpancé en la categoría de gatos.

Hay similitudes con las implementaciones de MVU, como una vista inmutable. Pero hay diferencias claras, como que no hay un bucle de mensajes ni una función de actualización explícita. El modelo se muta directamente en la Vista. Esto es algo que la gente explícitamente no quería cuando se les ocurrió MVU. En algunos idiomas incluso sería imposible hacer eso, por eso surgió MVU. Y por qué se hizo popular. Ahora debemos tener cuidado si eliminamos esas propiedades de nuestra definición de MVU.

@forki : No estoy en contra de lo que dijiste. De hecho, son esos puntos que mencionó en el último comentario los que debemos discutir como comunidad y no titular en una publicación de blog. Ese es mi punto. Eso es algo positivo para discutir y el marco se beneficiará de ello.

Estoy de acuerdo en que el nombre es un pequeño detalle que no debe distraer la atención de aspectos más importantes. Sin embargo, la razón por la que lo mencioné es que personalmente no veo a MAUI como un esfuerzo de la comunidad donde el sentido común eventualmente conducirá a una solución acordada en común. Es un producto de Microsoft donde las decisiones finales se toman a puerta cerrada. Estoy aquí en mi calidad de cliente para plantear mis inquietudes.

Pero estoy seguro de que todos estamos de acuerdo en que el patrón arquitectónico más cercano para todos estos marcos es MVU.

@ libin85 No estoy de acuerdo, este es el patrón arquitectónico más cercano. MVU es un conjunto de restricciones contra lo que se ve más generalmente como MVP o Model View Presenter. MVVM es similar, tomando una dirección diferente en el sentido de que su presentador es un modelo de vista con enlaces de datos. MVP en sí mismo es una forma restringida de MVC. Creo que es bastante seguro decir que todos estos son descendientes de MVC e incluso de MVP, pero decir que MVU se aplica a SwiftUI, Flux, etc. es hacer de MVU un término sin sentido.

Estoy de acuerdo en que el nombre es un pequeño detalle que no debe distraer la atención de aspectos más importantes.

No, los nombres son importantes. Son difíciles, tanto de establecer como de retener su significado. Ver también REST, que discutí anteriormente. Se abusa tanto de REST que ya no tiene sentido excepto como término de la jerga de marketing. Me gustaría que eso no le suceda a MVU, especialmente cuando hay términos existentes para lo que proporciona "MVU" de MAUI.

Por lo que vale, creo que MAUI "MVU" es una buena alternativa a la opción MVVM. Al igual que con REST, no tiene que hacer la definición para hacer algo útil y bueno. Simplemente no enturbie el nombre con alternativas que claramente se desvían de un patrón bien definido y establecido. Después de todo, MVU _también_ sería una buena alternativa a las opciones MVVM y Comet.

Por lo que vale, creo que MAUI "MVU" es una buena alternativa a la opción MVVM. Al igual que con REST, no tiene que hacer la definición para hacer que algo sea útil y bueno, solo no enturbie el nombre con alternativas que claramente se desvían de su definición.

RECONOCIMIENTO COMPLETO.

¿Por qué lo nombrarían MSMVU? Comet ha sido MVU y seguirá siéndolo. Y Maui es una MVU.

@saint4eva se "comercializan" como, pero por definición no, MVU.

Estoy de acuerdo en que el nombre es un pequeño detalle que no debe distraer la atención de aspectos más importantes.

No, los nombres son importantes. Son difíciles, tanto de establecer como de retener su significado. Ver también REST, que discutí anteriormente. Se abusa tanto de REST que ya no tiene sentido excepto como término de la jerga de marketing. Me gustaría que eso no le suceda a MVU, especialmente cuando hay términos existentes para lo que proporciona "MVU" de MAUI.

Por lo que vale, creo que MAUI "MVU" es una buena alternativa a la opción MVVM. Al igual que con REST, no tiene que hacer la definición para hacer algo útil y bueno. Simplemente no enturbie el nombre con alternativas que claramente se desvían de un patrón bien definido y establecido. Después de todo, MVU _también_ sería una buena alternativa a las opciones MVVM y Comet.

Estoy de acuerdo con la mayoría de lo que dijiste, pero creo que "Maui MVU" sigue siendo tan malo y confuso. Probablemente iría con "Maui MVP" o MVC. Ambos funcionan y están más cerca de lo que se presenta en la publicación del blog que MVU.

Editar añadir:
Ni siquiera estoy seguro de dónde vive la versión propuesta. Me refiero a que la lógica en MVVM vive en ViewModel, con MVU vive dentro de la función de actualización y con MVP vive en el Presentador y con MVC vive en el Controlador.

¿Va a haber una Vista en la que viva todo? ¿O todo vive en una clase nombrada por el modelo de dominio que sirve a la vista, la lógica y el modelo? ¿Se supone que los modelos son clases (tipos) o registros separados?

Creo que este es para mí el mayor problema aquí, no tengo idea de cómo se "presenta" y, por lo tanto, no puedo ver que haya una función de actualización, modelo y vista.

Fuera de la caja, me parece que MAUI es un nivel un poco más bajo que los patrones discutidos hasta ahora, en realidad solo el modelo (o estado) y la parte de vista de esos otros patrones. Algo en lo que quizás podría construir para implementar esos otros patrones (aunque la gestión estatal es un poco obstinada).

Entonces, por ejemplo, si T en State<T> es una clase similar a ViewModel, y agrega un conjunto separado de clases de modelo de datos, entonces terminaría con algo como MVVM con una vista unidireccional.

Por otro lado, si agrega un sistema de gestión de estado similar a Redux y conecta el modelo de estado de Redux como su T en State<T> , entonces lo que obtiene es algo muy parecido a MVU , aunque no tan completamente integrado como una MVU tradicional como Elm/Fabulous. ¿Tal vez podría ocultar las vistas de MAUI detrás del marco de MVU, como lo hace Fabulous con Xamarin.Forms?

No estoy seguro de cómo implementaría un patrón MVC o MVP sobre MAUI. Como primer paso aproximado, estoy pensando que tal vez si creara una clase separada que exponga "acciones" a la función de vista. Por ejemplo, supongamos que tiene un cuadro de diálogo de confirmación de MAUI y su clase de "controlador" tiene un método "ClickOK" y un método "ClickCancel". La vista MAUI reenviaría los eventos de clic de la vista al controlador, que generaría un nuevo modelo o mutaría el modelo existente.

@JeroMiya Estoy de acuerdo, definitivamente usar el patrón Redux puede acercarlo a MVU y mantiene la arquitectura mucho menos opinada. Soy un usuario feliz de React-Redux, React-Hooks, ReactiveX y últimamente de Blazor Apps :heart: Fluxor :heart: . @mrpmorris puede contribuir con esta conversación.

Aquí está mi intento de un ejemplo de C#. No tengo MAUI disponible para probar esto como un ejemplo real. No hay vista previa, ¿verdad? De todos modos, esta es una traducción aproximada de la idea.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

¿Incurriría esto en un mayor costo de rendimiento para las actualizaciones que en la muestra de Microsoft? En este modelo, si entiendo, se crearía una instancia de una nueva vista que contiene todos los elementos de la interfaz de usuario, en lugar de, en la muestra de MS, dejar los elementos de vista existentes en su lugar y simplemente actualizar el valor de la etiqueta (un incurrir en cualquier re -costo de dimensionamiento que esto podría tener).

Esta diferencia parece ser una de las diferencias centrales que impulsan esta discusión sobre la denominación, por lo que tengo curiosidad si en la arquitectura MVU definida tradicionalmente existen otras técnicas para actualizar la interfaz de usuario de manera eficiente y, de ser así, ¿están implementadas al nivel de la motor de renderizado?

@markmccaigue con respecto al rendimiento: a menudo, los sistemas MVU vienen con una vista virtual (o DOM virtual en el caso de html) y un motor de diferenciación. Entonces, después de diferenciar DOM con DOM virtual, el marco solo necesita aplicar un parche al DOM. Esto suele ser muy, muy eficiente, especialmente si trabaja con estructuras de datos inmutables.

¡¡Hola!!

Voy a cerrar este problema por ahora. Me gustaría hacer de esto una discusión, pero github no quiere que eso funcione :-/

Si alguien quiere continuar esta conversación, cree un elemento de discusión y luego haga referencia a este problema.