Maui: MVU pode não ser o que você pensa que é

Obrigado @aspnetde , espero que você se junte a nós enquanto trabalhamos na implementação dessa ideia nos próximos 18 meses. Dada a sua história com o MVU, espero que você tenha muito a contribuir.

Eu acho que é muito cedo para dizer que o .NET MAUI é ou não é MVU, já que ainda não o construímos . :)

Sim, temos um protótipo. Sim, é inspirado no experimento do Cometa. E sim, sabemos que existe a preocupação de que o que mostramos até agora não corresponda à definição de MVU de todos.

Minha esperança é que possamos colaborar! Se o que acabamos projetando e enviando merece um rótulo diferente, concordo que devemos dar um.

Como você esperaria ver o C# MVU no .NET MAUI?

Quais novos recursos de linguagem você consideraria necessários, se houver?

Podemos/devemos considerar a integração do Fabulous e/ou quais padrões faz sentido tornar comum entre C# e F#, e o que deveria ser diferente?

Como você esperaria ver o C# MVU no .NET MAUI?

Você já ouviu alguém dizendo C# MVC ou C# MVVM? _Model-View-Update_ também conhecido como _The Elm Architecture_ é um padrão de arquitetura bem definido, não uma implementação dependente de linguagem.

Quais novos recursos de linguagem você consideraria necessários, se houver?

• Embora os tipos de união ajudem a simplificar a definição de mensagens massivamente, isso pode ser feito por meio de interfaces/classes abstratas e uma subclasse por mensagem, embora isso exija um pouco mais de código clichê para escrever.
• Para processar mensagens, a correspondência de padrões é útil se não for necessária. Acho que o estado atual das expressões de switch C# já é bom o suficiente para isso, pois a forma das mensagens será simples.
• Por último, mas não menos importante, o recurso mais importante que vejo é a imutabilidade por padrão e as comparações de igualdade estrutural habilitadas. Pelo que me lembro da proposta atual de registros em C# 9 (classes de dados), eles vão entregar exatamente isso.

Portanto, o C# 9, embora ainda seja mais barulhento que o F#, seria bom para ir do meu ponto de vista atual.

Podemos/devemos considerar a integração do Fabulous e/ou quais padrões faz sentido tornar comum entre C# e F#, e o que deveria ser diferente?

Conforme escrito acima, não deve haver nada particularmente específico de linguagem na abordagem geral, pois o próprio MVU é apenas o estilo de arquitetura ou o modelo de aplicativo como você o chama.

@TimLariviere fez algumas propostas para avançar o Fabulous recentemente, que também inclui ideias em torno de um DSL mais semelhante ao SwiftUI. Você pode querer dar uma olhada e/ou se envolver lá também.

A propósito: fiz uma comparação 1:1 de XF + C# + MVVM e XF + F# + MVU no ano passado, os resultados podem ser encontrados aqui – incluindo o código-fonte.

Eu acho que é muito cedo para dizer que .NET MAUI é ou não é MVU

Não é sobre se MAUI será MVU no final. É sobre a amostra no blog de anúncios que já gerou tanta confusão na comunidade. Basicamente, tenho que assumir que os autores ainda não analisaram o MVU. Falar sobre "C# MVU" não torna isso melhor.

Concordo com @aspnetde e @forki o problema aqui está na comunicação.

Acho que nenhum de nós está discutindo para descartar ou alterar o C# DSL inspirado em cometa para MAUI/XF, mas mesmo se considerarmos o que está sendo feito até agora, isso ainda está usando o conceito de ligação sublinhado que faz parte do padrão MVVM .

Isso é algo que tenho perguntado repetidamente em comunicação direta e também em questões, talvez seja uma boa ideia para todos os envolvidos lerem padrões diferentes, como MVVM e MVU.

Dito isto, existe até uma maneira de implementar o MVU em cima do MVVM, mas a questão permanece: qual problema isso resolveria.

Você já ouviu alguém dizendo C# MVC ou C# MVVM?

Sim, eu entendo que é estranho dizer C# ou XAML seguido por um padrão de arquitetura como MVVM ou MVU. Entre a comunidade mais ampla de desenvolvedores com quem falo, há a necessidade de deixar claro que você pode utilizar qualquer número de combinações em seu projeto. A intenção não é dizer que um "C# MVVM" é arquiteturalmente diferente de "XAML MVVM", mas que a combinação é possível e a experiência do desenvolvedor como um todo é, portanto, ligeiramente diferente.

Eu pensei que este tópico poderia discutir como o MVU ficaria no .NET MAUI, mas talvez a discussão mais produtiva aqui seja como falamos sobre várias experiências de desenvolvedor e padrões de arquitetura em um único produto?

Parece que essa é a direção da maioria dos comentários aqui, querendo discutir o que chamamos e rotulamos as coisas e como usamos os termos. Eu adoraria muito sua opinião sobre isso, já que faço grande parte da comunicação e quero ter certeza de que estou realmente adicionando clareza e não gerando confusão.

É sobre a amostra no blog de anúncios que já gerou tanta confusão na comunidade.

Essa foi minha contribuição para o blog e peço desculpas pela confusão que criou para você. Calculei mal que, ao adicionar links para o blog do Elm e

Basicamente, tenho que assumir que os autores ainda não analisaram o MVU.

Tivemos uma extensa conversa e debate sobre o tema. Por favor, não assuma, e eu tentarei não fazer isso também.

a questão permanece que problema resolveria.

@dersia o problema geral a ser resolvido é dar escolha aos desenvolvedores. Se você está perguntando o que o MVU em cima do MVVM resolve, não tenho ideia - isso não é algo que está sendo solicitado ou algo que estamos tentando fazer.

A refatoração proposta em #28 e #66 é parcialmente sobre separar as coisas específicas de databinding e MVVM das implementações do renderizador, de modo que, se você optar pelo MVU, não terá recursos adicionais usados ​​no MVVM.

Eu não previ quanto peso o trecho de código teria

Mas essa é a carne, certo? E lamento que não corresponda ao rótulo.

@davidortinau

Parece que essa é a direção da maioria dos comentários aqui, querendo discutir o que chamamos e rotulamos as coisas e como usamos os termos. Eu adoraria muito sua opinião sobre isso, já que faço grande parte da comunicação e quero ter certeza de que estou realmente adicionando clareza e não gerando confusão.

Não tenho certeza do que resta a acrescentar do meu lado. Acho que expressei minha posição em alto e bom som :-). Se você for implementar o MVU, você empurrará uma porta aberta. Se é o que pode ser presumido olhando para o trecho na postagem de anúncio e no repositório Comet, sinta-se à vontade para fazê-lo – mas _por favor_ pare de chamá-lo de MVU.

Obrigado.

Como Don foi mencionado neste tópico :-) - CC: @dsyme

Eu não entendo por que isso está sendo chamado de MVU, quando não é. Pode ser um grande paradigma e funcionar muito bem aqui - por que não criar um termo adequado que se encaixe no paradigma e não confunda?

@aspnetde o que sobrou do seu lado? Muito eu suponho :).
Li algumas partes da sua tese. Devo dizer que gostei. Eu também li o livro de Don Syme sobre F#. Gosto de programação funcional. Pela minha experiência, é conciso, mas difícil de entender (entender). A legibilidade é uma parte muito importante do ciclo de vida do desenvolvimento. Muito do tempo é realmente gasto na leitura de código. E a recursão é somente escrita. Você pode escrevê-lo uma vez, mas quase ninguém pode lê-lo (semelhante ao regexp).
No passado eu tentei Redux com Angular durante meu tempo de prototipagem/pesquisa na empresa. É uma abordagem meio Elmish? Foi uma experiência valiosa. Aprendi que tenho que tomar cuidado para não alterar o estado e, como resultado, não precisarei lembrar de toda a pilha, onde exatamente o estado pode mudar repentinamente.
Eu entendo os benefícios da imutabilidade, mas vi uma apresentação com Erik Meijer que de repente rasgou uma cabeça de ursinho de pelúcia, para nos mostrar que o mundo real é mutável.

Então o que eu gostaria de salientar: nosso pensamento natural não é contrário a esses paradigmas? Qual é a sua experiência?

Eu tenho muita experiência com XAML/C#/MVVM, então estou me perguntando por que Don Syme considera o XAML desnecessário.
Pela minha experiência, ajuda a separar as preocupações (IU, apresentação, lógica de negócios, etc.). Não tenho certeza se essas DSLs (marcações C#) e MVU estão ajudando a melhorar a qualidade do código a longo prazo. Desenvolvedores não experientes/que não se importam vão misturar as responsabilidades. Eu também preciso de mais experiência com o padrão MVU, para entendê-lo corretamente, mas você tentou esses dois paradigmas e é muito valioso para toda a comunidade.
Por favor, compartilhe o máximo que puder. Obrigado @aspnetde!

Muito obrigado (a todos) pela sua compreensão

@davidortinau talvez tenha havido um mal-entendido aqui, sou totalmente a favor da escolha e deixando que cada um escolha por si mesmo qual padrão/paradigma usar. Eu estava apenas tentando dizer que devemos nomear as coisas corretamente. Como todos no desenvolvimento de software sabem que nomear as coisas é uma das coisas mais difíceis de fazer, mas se já houver coisas bem definidas nomeadas, não devemos começar a reutilizar esses nomes para coisas que não são.

Falta de comunicação A falta de comunicação é um dos maiores problemas do nosso mundo hoje, acho que como comunidade, como colaboradores de um projeto, como projeto líder, devemos ajudar todos a entender as coisas e também devemos estar abertos a críticas e admitir erros e nos unir para consertar isso.
Neste caso, acho que o uso de palavras erradas precisa ser corrigido e, para que isso aconteça, eu adoraria que este projeto
a) entender que MVU é o nome errado para o que estamos falando aqui
eb) encontrar o termo certo para descrever o que estamos tentando estabelecer aqui
e então c) atualizar todos e começar a usar esse novo nome

Acho que ainda estamos em um ponto em que ainda podemos voltar e consertar. Vamos fazer direito, a pior coisa que pode acontecer é que a comunidade XF/Maui entenda o MVU como algo diferente do resto do mundo.

Dito isso, sou um grande fã do MVU e também adoro o MVVM, e acho que a abordagem fluente do MVVM (ainda não tenho um nome melhor) como no Comet e o que foi apresentado até agora é ótimo e ajuda um muitos desenvolvedores e eu vou apoiá-lo, só acho que devemos corrigir o nome.

Edit: comunicação de miss saiu do concurso.

Eu entendo os benefícios da imutabilidade, mas vi uma apresentação com Erik Meijer que de repente rasga a cabeça de um ursinho de pelúcia, para nos mostrar que o mundo real é mutável.

@tomasfabian isso está errado.

Você tem que começar a ver o mundo como uma série de eventos, isso é o que realmente é (não, eu não quero começar uma discussão sobre o fornecimento de eventos aqui).
O que aconteceu com o ursinho de pelúcia é apenas que um novo evento foi adicionado ao seu estado, o evento neste caso é "arrancado da cabeça". E como você pode perceber que uma vez que um evento aconteceu, você não pode reverter, pois você não pode simplesmente desfazer ou excluir o que acontece. Para colocar a cabeça de volta no ursinho, você precisaria de um novo evento chamado "cabeça costurada de volta ao corpo". 😉

Discutir os benefícios ou não de FP e MVU é IMHO off topic aqui. Esse problema era, pensei, apenas sobre o potencial de falha de comunicação e nomeação precisa.

@isaacabraham talvez você esteja certo, e peço desculpas por isso. É minha culpa. Eu sei que nomear as coisas é importante, mas por outro lado o título da edição é "MVU pode não ser o que você pensa que é". Portanto, espero que seja um tópico um pouco mais amplo do que nomear as coisas.
Obrigado, Tomas

@tomasfabian Eu ficaria super feliz em conversar com você sobre os prós e contras do MVU, FP ou qualquer outra coisa, real ou imaginária 😊 Só não pense que este é o fórum apropriado para isso.

@davidortinau
Quanto a quais recursos de linguagem e mudanças de arquitetura seriam úteis, espero poder contribuir com algumas sugestões:

* A palavra-chave new e outros ruídos sintáticos.
Ao contrário do Dart ou Kotlin, o C# provavelmente está preso a uma palavra-chave new obrigatória para sempre, já que torná-la opcional é uma mudança importante e uma proposta impopular, mesmo como uma diretiva opt-in por arquivo. Então, em vez disso, talvez uma classe estática oficial (e mantida) (ou uma classe estática por namespace de exibição MAUI) contendo métodos estáticos que apenas envolvem construtores e inicializam quaisquer propriedades somente de inicialização, se houver, pelo menos para o conjunto principal de Objetos de visualização MAUI. Então podemos colocar uma diretiva using static no topo de nossos arquivos .cs de código de visualização e então chamar os métodos sem o ruído sintático de new . Isso reduziria um pouco a confusão e o ruído das funções de exibição C#. É claro que esses wrappers construtores de métodos estáticos podem ser gerados automaticamente pela comunidade (eu fiz algo semelhante para Xamarin.Forms usar com CSharpForMarkup), mas seria bom ter um conjunto na caixa deles mantido por o projeto MAUI.

Além disso, quaisquer propostas de linguagem C# que ajudem a reduzir a desordem ou o ruído sintático em grandes árvores de expressão (como é comum nas funções de exibição MVU/Comet/CSharpForMarkup) ajudariam muito. O C#9 percorreu um longo caminho nesse sentido para melhorar as partes M e U do MVU, mas a parte V ainda é um ponto problemático em termos de sintaxe.

* Propriedades da extensão *
Eu sei que a proposta "extensão-tudo" está em espera por enquanto, mas uma coisa que poderia ser útil para MVVM-com-C#-markup (por exemplo, CSharpForMarkup com Xamarin.Forms), seriam propriedades de extensão. Com o CSharpForMarkup, todo auxiliar tinha que ser implementado usando um método de extensão, mas em alguns casos uma propriedade de extensão (que pode ser usada no inicializador de objeto) ficaria muito melhor:

// 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",
    };

Isso realmente se aplica apenas a árvores de objetos de exibição mutáveis, como no MVVM com C# para marcação. Para MVU ou outras arquiteturas de interface do usuário funcional, isso não é aplicável, pois os objetos de exibição são imutáveis. Nesses casos, um método de extensão fluente é ainda mais apropriado.

* Seja menos opinativo (ou de baixo nível, se preferir) sobre a gestão do estado *
Acho que uma das maiores barreiras para a implementação de MVU em cima do Xamarin.Forms foi a falta de dois componentes essenciais: o gráfico de objeto leve que as funções de exibição poderiam retornar, que o framework poderia "renderizar" em componentes reais (com seus representações específicas da plataforma, etc...). E a segunda peça é um mecanismo de comparação que atualiza eficientemente as visualizações específicas da plataforma pesada, procurando diferenças entre um valor de retorno de uma função de visualização e outra, incluindo uma maneira de fazer diferenças de forma eficiente fazendo diferenças parciais, etc ...

Parece que a MAUI agora está fornecendo essas duas peças essenciais, o que é ótimo! No entanto, parece, pelo menos no nível superficial, estar intimamente ligado a uma maneira opinativa de gerenciar o estado que alguns na comunidade MVU diriam que está mais próximo do MVVM do que o MVU ou arquiteturas de interface do usuário "funcionais" semelhantes. Acho que minha preferência seria manter as duas peças essenciais que mencionei acima (gráfico de objeto de visualização leve e mecanismo de diferenciação eficiente) e casá-lo com um sistema de componentes de nível inferior no qual o MVU ou o Comet poderiam ser colocados em camadas de forma eficiente, de acordo com o desenvolvedor escolha. Talvez esse já seja o objetivo, e eu não estou vendo? Se sim, eu adoraria ver mais discussão sobre isso com pelo menos alguns exemplos básicos.

@aspnetde por que você excluiu sua postagem?

@tomasfabian

Pela minha experiência, [MVVM] ajuda a separar as preocupações (IU, apresentação, lógica de negócios, etc.)

Sim. Eu fiz algumas boas experiências com grandes aplicativos Xamarin.iOS e Xamarin.Android construídos com MvvmCross. Embora eu prefira bibliotecas a frameworks hoje, acho que todos esses projetos (alguns com LOC de seis dígitos) foram um sucesso, tanto tecnicamente quanto do ponto de vista comercial.

Eu acho que o MVVM faz um bom trabalho especialmente quando se trata de dimensionar um aplicativo. Especialmente em dispositivos móveis, onde somos forçados a enviar monólitos, isso nos ajudou a refatorar nossos aplicativos em módulos independentes depois que eles passaram de um determinado tamanho.

Nosso pensamento natural não é contra esses paradigmas ([MVU])? Qual é a sua experiência?

Acho que não. Leve sua experiência com Redux para o armazenamento e imagine toda a sua aplicação para se beneficiar de suas vantagens. Embora pareça mais complexo à primeira vista, na minha experiência é muito mais simples de entender e trabalhar. Como o @forki costuma apontar, é quase chato porque o fluxo de dados unidirecional deixa claro o que acontece o tempo todo.

Não tenho certeza se essas DSLs (marcações C#) e MVU estão ajudando a melhorar a qualidade do código a longo prazo.

Embora o MVU e o MVVM tenham vantagens diferentes, ambos também têm desvantagens diferentes.

Apesar de considerarmos nossos projetos MVVM bem-sucedidos, minha equipe e eu perdemos um pouco de cabelo ao depurá-los. Em um projeto em particular, começamos a sofrer com a complexidade causada pela falta de experiência dos novos membros da equipe e mal-entendidos – como você já apontou. Acho que isso é menos provável no MVU quando aplicado estritamente, porque define os limites de como as coisas funcionam tão estreitamente, que é quase mais difícil sair disso e construir as coisas de maneira errada, do que o contrário.

Para MVU vejo dois grandes problemas. Primeiro: Escala. Muitos estão defendendo um único programa. Eu sou cético aqui (e acho que vários programas/módulos seriam uma maneira melhor). Segundo: agora, uma coisa como Fabulous fica em cima do Xamarin.Forms. Portanto, é uma camada de abstração em cima de uma camada de abstração em cima de uma camada de abstração em cima do iOS/Android. Isso é uma enorme quantidade de complexidade. Assim, você não apenas lida com bugs não resolvidos com os quais ninguém se importa, mas também é um trabalho mais ou menos tedioso e desagradável atualizar uma camada de abstração (Fabulous) quando a outra (Xamarin.Forms) muda.

É aí que eu veria uma grande chance para o MAUI. Sinceramente, adoraria ver os mantenedores do Fabulous unindo forças com a Microsoft aqui. E eu realmente espero que a Microsoft não o estrague, como outras partes da organização fizeram no passado.

Thomas

Quando estava lendo o anúncio oficial outro dia, fiquei surpreso com o que foi apresentado lá 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 ++)
    )
};

No que me diz respeito, isso não é MVU . Eu já escrevi alguns pensamentos sobre por que eu penso assim aqui .

Don Syme, que, pelo que entendi, passou vários meses de 2018 implementando MVU em cima do Xamarin.Forms e construindo o que mais tarde se tornou Fabulous , é um pouco mais diplomático , mas o resultado final é o mesmo.

Então, qual é o meu ponto?

• Eu adoraria que você implementasse o padrão arquitetural real, não importa se em C# ou F#. Alcançar as pessoas por trás do Fabulous pode ser um começo aqui.
• Se você não está interessado nisso, mas tem uma visão clara de como desenvolver o que está disponível hoje como a biblioteca Comet , considere usar um nome mais apropriado para esse "modelo de aplicativo". Invente algo novo. Nomeie-o MSMVU. Qualquer que seja. Mas não venda maçãs por laranjas.

Felicidades!

Por que eles o chamariam de MSMVU? Comet foi MVU, e continuará assim. E Maui é um MVU.

Eu acho que é muito cedo para dizer que .NET MAUI é ou não é MVU

Não é sobre se MAUI será MVU no final. É sobre a amostra no blog de anúncios que já gerou tanta confusão na comunidade. Basicamente, tenho que assumir que os autores ainda não analisaram o MVU. Falar sobre "C# MVU" não torna isso melhor.

Não causa qualquer tipo de confusão. É só que algumas pessoas não conseguem lidar com isso vendo C# fazendo MVU.

Por que vale a pena, SwiftUI (do qual Comet tira a maior parte de sua inspiração) tende a chamar seu padrão de MVVM, mesmo que não haja diretrizes explícitas.
Eu não encontrei nenhuma menção ao MVU embora.

@TimLariviere https://github.com/Clancey/Comet#key -concepts
Basicamente o Comet chamou de MVU e já está faltando o ponto do loop de mensagens que temos nas definições mais antigas de MVU

Por que vale a pena, SwiftUI (do qual Comet tira a maior parte de sua inspiração) tende a chamar seu padrão de MVVM, mesmo que não haja diretrizes explícitas.

Nem está errado, olhando o exemplo no início deste post aqui: https://nalexn.github.io/clean-architecture-swiftui/

Eu não encontrei nenhuma menção ao MVU embora.

O mesmo post também discute brevemente (como uma combinação de SwiftUI + Redux = TEA). Embora esteja então a dar uma guinada estranha para "Arquitetura Limpa" 😄

Já que fui mencionado aqui, vou apenas dizer algumas coisas.

• Acho o MAUI ótimo e acho que aprender sobre MVU como uma arquitetura pode ser útil para as pessoas entenderem o MAUI.

• É fácil ficar preso às palavras, e provavelmente todos deveríamos respirar e tentar não nos preocupar com isso neste estágio, já que há muito tempo para ajustar as palavras que são usadas e acho que a mensagem sobre terminologia precisa foi ouviu. Pessoalmente, acho que Elm estabeleceu que o uso sem adornos e não qualificado de "MVU" significa mensagens explícitas, atualização explícita, modelos funcionais, recálculo de visão funcional e atualização diferencial. Mas existem muitas variações de MVU e MAUI é um ponto nesse espectro (que cobre todo o caminho até o MVVM como uma espécie de sistema de processamento de mensagens incrementado manualmente com estado mutável implícito e abrangente). A comunicação SwiftUI é interessante nessa perspectiva.

• Percebo que as pessoas tendem a ter crenças e opiniões muito fortes nessa área e podem levar as coisas para o lado pessoal. Eu sei como é isso e, como o design da linguagem de programação, acho que todos os pontos no espaço têm prós e contras. Eu encorajo todos a experimentar, usar, aprender, compartilhar e trabalhar juntos para fazer a melhor gama de tecnologias possível.

@dsyme
Acho que o termo adequado para a arquitetura Comet/MAUI é uma variação do fluxo de dados unidirecional (ou UDF), mas não MVU, pois o MVU é em si uma variação muito específica do UDF. O MAUI/Comet certamente se qualifica como um framework UDF (assim como o SwiftUI), mas não se qualifica como um framework MVU. Existem várias variações de UDF, incluindo MVU, Flux, Redux, React, etc... mas é uma falha de comunicação chamar o Comet MVU quando não é MVU.

Ao contrário do MVU, o modelo é mutável e é modificado pelo código na função View. As mutações são então observadas e as visualizações reagem a essas mutações ao renderizar novamente. Ainda é unidirecional porque as visualizações não são alteradas, mas não há função de atualização, mensagens e envio de mensagens - portanto, não MVU. Está mais próximo de uma variação unidirecional do MVVM.

@JeroMiya Obrigado, você tem uma referência para essa terminologia?

@dsyme Não tenho uma referência específica para isso, mas comecei a ouvir o termo sendo usado nos primeiros dias do React, especificamente em referência ao próprio React e a alguns dos primeiros padrões que surgiram, como Redux e Flux. Lembro-me de um artigo que descrevia várias variantes de UDF (principalmente no espaço React), mas não consigo encontrá-lo agora.

Dito isto, não é uma arquitetura formal - mais como apenas o conceito básico da visão ser uma função do modelo, em oposição à visão ser uma árvore de objetos com estado que muda em resposta a eventos. O conceito de UDF não especifica necessariamente como o modelo é atualizado ou se é mutável ou imutável. A MVU estende o conceito de UDF não apenas para a visualização em si, mas também para o processo de atualização do modelo. Assim, no MVU, o modelo também é imutável, e as mudanças de estado da interface do usuário são representadas como comandos que produzem novos modelos, que acionam novas visualizações.

Não é um conceito novo, é claro - mesmo antes do React, a maioria dos frameworks da Web do lado do servidor como Asp.Net MVC, Rails e até PHP tecnicamente contam como unidirecional. Simplesmente não era comum para estruturas de SPA convencionais e estruturas de UI do lado do cliente antes do surgimento do React.

@dsyme Não tenho uma referência específica para isso, mas comecei a ouvir o termo sendo usado nos primeiros dias do React, especificamente em referência ao próprio React e a alguns dos primeiros padrões que surgiram, como Redux e Flux. Lembro-me de um artigo que descrevia várias variantes de UDF (principalmente no espaço React), mas não consigo encontrá-lo agora.

Dito isto, não é uma arquitetura formal - mais como apenas o conceito básico da visão ser uma função do modelo, em oposição à visão ser uma árvore de objetos com estado que muda em resposta a eventos. O conceito de UDF não especifica necessariamente como o modelo é atualizado ou se é mutável ou imutável. A MVU estende o conceito de UDF não apenas para a visualização em si, mas também para o processo de atualização do modelo. Assim, no MVU, o modelo também é imutável, e as mudanças de estado da interface do usuário são representadas como comandos que produzem novos modelos, que acionam novas visualizações.

Não é um conceito novo, é claro - mesmo antes do React, a maioria dos frameworks da Web do lado do servidor como Asp.Net MVC, Rails e até PHP tecnicamente contam como unidirecional. Simplesmente não era comum para estruturas de SPA convencionais e estruturas de UI do lado do cliente antes do surgimento do React.

@JeroMiya obrigado por isso, é exatamente assim que eu entendo o MVU.
Eu diria até que um dos aplicativos mais antigos e ainda mais usados ​​que usa e exemplifica o MVU em sua melhor forma é o MS Excel.

@dsyme lendo seus comentários, tenho a sensação de que você está se referindo a MAUI como o termo para a arquitetura discutida (CSharpForMarkup com MVVM).
Por favor, esclareça para mim que isso não é o que você entende como MAUI ou se é.
Do meu entendimento, MAUI é apenas o próximo MS Application Framework para substituir o XF em algum momento no futuro.

Eu realmente gosto da maneira como esta questão e seus comentários estão indo. Obrigado pela participação de todos. Talvez juntos possamos obter todas as diferentes arquiteturas como possíveis sabores para MAUI estabelecidas e nomeadas corretamente.

@dersia Obrigado! Apenas uma observação da minha própria experiência com CSharpForMarkup: é um nível um pouco inferior ao MVVM - mais um conjunto de métodos e utilitários de extensão para tornar a marcação C# mais simplificada e com melhor aparência. Você certamente pode implementar um padrão MVVM com ele, pois possui ajudantes para facilitar as ligações do ViewModel, mas o que acabei fazendo foi implementar toda a minha lógica de visualização no Redux em vez de ViewModels. Só precisava adicionar alguns métodos de extensão para vincular propriedades de visualização a seletores de estado, que são apenas Func<StateType, ChildStateType> eu passo para os operadores Select e DistinctUntilChanged no armazenamento de estado Redux, que é um Observable<StateType> . Fluxo de dados não muito unidirecional, mas eu não tinha uma maneira madura de fazer diferenças de árvore de objetos de interface do usuário e funções de exibição como o Fabulous faz agora.

Algum tempo atrás, a polícia do REST tentou enfiar goela abaixo que todos nós não deveríamos ser chamados de REST. Todo mundo ainda chama isso de REST hoje e ainda estamos todos vivos e bem. 😉

@bitbonk a comunidade REST desistiu do termo porque se tornou cada vez mais inútil à medida que mais e mais coisas eram lançadas na mistura. Eles agora usam “hipermídia” para se referir à Transferência de Estado Representacional. REST, hoje, agora realmente significa apenas “não SOAP” ou “JSON sobre HTTP”, nenhum dos quais consegue comunicar sua ideia central. Os comentaristas aqui esperam evitar o mesmo destino para o MVU.

@davidortinau @tomasfabian , ainda não vi um exemplo de MVU no MAUI. Vou tentar elaborar um exemplo esta noite. Acabei de fazer algo semelhante para WinForms aqui . Suponho que não deve ser muito difícil.

@JeroMiya Obrigado, você tem uma referência para essa terminologia?

@dsyme , acho que se originou com o React Flux, mas eles apontaram para arquiteturas de jogos, ou seja, Doom 3. Acho que me lembro de discutir isso com @TIHan quando foi apresentado pela primeira vez.

• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/unidirectional-data-flow

Aqui está minha tentativa de um exemplo C#. Eu não tenho MAUI disponível para tentar isso como um exemplo real. Não há prévia, não é? De qualquer forma, esta é uma tradução aproximada da ideia.

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);

Uma vez tentei brevemente

Sou relativamente novo no MVU e provavelmente tenho muito pouca experiência em usá-lo em comparação com muitos de vocês. Mas os conceitos de MVU definitivamente chamaram meu interesse, e estou gostando. Estou muito feliz em ver que os desenvolvedores de C# recebem uma estrutura para ajudar a desenvolver no padrão MVU.

Concordo totalmente que o MAUI MVU não é o MVU típico e tem uma enorme influência do SwiftUI. Seu principal autor, Clancey himeslef, deixou isso bem claro em quase todas as suas sessões. Todos nós sabemos que o Redux é altamente influenciado pelo MVU, assim como SwiftUI, Flutter e muitos outros frameworks. Nenhum deles é MVU puro.

Mas tenho certeza de que todos concordamos que o padrão de arquitetura mais próximo para todos esses frameworks é o MVU. Essa é a razão pela qual as pessoas o referem. E lembre-se que estamos falando de um título de blog para um framework que será lançado daqui a um ano e meio.

E se você disser que as pessoas estão ficando bravas com o título deste blog. Acho que não devemos nos preocupar com eles. A comunidade ainda precisa continuar. Vamos gastar nossa energia para melhorar essa estrutura. Não se preocupe muito com os pequenos detalhes.

Mas tenho certeza de que todos concordamos que o padrão de arquitetura mais próximo para todos esses frameworks é o MVU. Essa é a razão pela qual as pessoas o referem.

Cães, cavalos, gatos e chimpanzés estão todos muito próximos uns dos outros. De agora em diante vou me referir a todos eles como gatos.

:) Bem, você não precisa. Mas deixe-me dizer uma coisa: gatos, tigres, leopardos etc são chamados de gatos. E eu estou feliz que você trouxe isso. Coz isso é exatamente o caso aqui.

@aspnetde : Thomas, com tudo isso dito. Eu preciso dizer que seu blog original do MVU é um dos melhores artigos que explica o conceito de forma muito clara e precisa. Tenho aprendido bastante com isso. Obrigada

@libin85 existe exatamente o problema. Você começou a enumerar coisas que realmente estão em uma categoria e ignorou as que não estão. Ao colocar a amostra MAUI na categoria MVU, você basicamente coloca um chimpanzé na categoria gatos.

Existem semelhanças com implementações de MVU, como uma visão imutável. Mas existem diferenças claras, como não há loop de mensagens e nenhuma função de atualização explícita. O modelo é modificado diretamente na View. Isso é algo que as pessoas explicitamente não queriam quando criaram o MVU. Em algumas linguagens seria até impossível fazer isso - é por isso que o MVU surgiu. E por que se tornou popular. Agora devemos ter cuidado se removermos essas propriedades de nossa definição de MVU.

@forki : Não sou contra o que você disse. Na verdade, são esses pontos que você mencionou no último comentário que precisamos discutir como uma comunidade e não o título de uma postagem no blog. Esse é meu argumento. Isso é uma coisa positiva para discutir e a estrutura vai ganhar com isso.

Concordo que o nome é um pequeno detalhe que não deve distrair de aspectos mais importantes. No entanto, a razão pela qual eu trouxe isso é que eu pessoalmente não vejo o MAUI como um esforço da comunidade onde o bom senso eventualmente levará a uma solução de comum acordo. É um produto da Microsoft onde as decisões finais são tomadas a portas fechadas. Estou aqui na minha capacidade como cliente para levantar minhas preocupações.

Mas tenho certeza de que todos concordamos que o padrão de arquitetura mais próximo para todos esses frameworks é o MVU.

@libin85 Discordo que este seja o padrão de arquitetura mais próximo. MVU é um conjunto de restrições contra o que geralmente se parece com MVP, ou Model View Presenter. O MVVM é semelhante, tomando uma direção diferente, pois seu Presenter é um ViewModel com vinculações de dados. O próprio MVP é uma forma restrita de MVC. Acho que é bastante seguro dizer que todos eles são descendentes de MVC e até mesmo MVP, mas dizer que MVU se aplica a SwiftUI, Flux, etc. é fazer de MVU um termo sem sentido.

Concordo que o nome é um pequeno detalhe que não deve distrair de aspectos mais importantes.

Não, os nomes são importantes. Eles são difíceis, tanto para estabelecer quanto para reter seu significado. Veja também REST, que discuti acima. REST é tão abusado que não é mais significativo, exceto como um termo de jargão de marketing. Eu gostaria de não ver isso acontecer com o MVU, especialmente quando existem termos existentes para o que o "MVU" do MAUI fornece.

Pelo que vale, acho que o MAUI "MVU" é uma boa alternativa à opção MVVM. Assim como com REST, você não precisa fazer a definição para fazer algo útil e bom. Apenas, por favor, não turve o nome com alternativas que claramente se desviam de um padrão bem definido e estabelecido. Afinal, MVU seria _também_ uma boa alternativa para as opções MVVM e Comet.

Pelo que vale, acho que o MAUI "MVU" é uma boa alternativa à opção MVVM. Assim como com o REST, você não precisa fazer a definição para fazer algo útil e bom, apenas por favor, não confunda o nome com alternativas que claramente se desviam de sua definição.

RECONHECIMENTO COMPLETO.

Por que eles o chamariam de MSMVU? Comet foi MVU, e continuará assim. E Maui é um MVU.

@saint4eva eles são "comercializados" como, mas por definição não, MVU.

Concordo que o nome é um pequeno detalhe que não deve distrair de aspectos mais importantes.

Não, os nomes são importantes. Eles são difíceis, tanto para estabelecer quanto para reter seu significado. Veja também REST, que discuti acima. REST é tão abusado que não é mais significativo, exceto como um termo de jargão de marketing. Eu gostaria de não ver isso acontecer com o MVU, especialmente quando existem termos existentes para o que o "MVU" do MAUI fornece.

Pelo que vale, acho que o MAUI "MVU" é uma boa alternativa à opção MVVM. Assim como com REST, você não precisa fazer a definição para fazer algo útil e bom. Apenas, por favor, não turve o nome com alternativas que claramente se desviam de um padrão bem definido e estabelecido. Afinal, MVU seria _também_ uma boa alternativa para as opções MVVM e Comet.

Concordo com a maioria do que você disse, mas acho que "Maui MVU" ainda é tão ruim e confuso. Eu provavelmente iria com "Maui MVP" ou MVC. Ambos funcionam e estão mais próximos do que é apresentado no post do blog do que o MVU.

Editar adicionar:
Eu nem tenho certeza de onde a versão proposta vive. Quero dizer, a lógica no MVVM vive no ViewModel, com o MVU vive dentro da função de atualização e com o MVP vive no Presenter e com o MVC vive no Controller.

Haverá uma Vista onde tudo vive? Ou tudo isso vive em apenas alguma classe nomeada pelo Modelo de Domínio que serve a visão, lógica e modelo? Os modelos devem ser classes (tipos) ou registros separados?

Eu acho que este é para mim o principal ponto de dor aqui, não tenho idéia de como ele é "apresentado" e, portanto, não consigo ver uma função de atualização, modelo e visualização.

Fora da caixa, parece-me que MAUI é um nível um pouco mais baixo do que os padrões discutidos até agora - realmente apenas o Modelo (ou Estado) e a parte View desses outros padrões. Algo que talvez você possa construir para implementar esses outros padrões (embora o gerenciamento de estado seja um pouco opinativo).

Então, por exemplo, se T em State<T> for uma classe do tipo ViewModel e você adicionar um conjunto separado de classes de modelo de dados, o que você terá é algo como MVVM com uma visão unidirecional.

Por outro lado, se você adicionar um sistema de gerenciamento de estado semelhante ao Redux e conectar o modelo de estado Redux como seu T em State<T> , o que você terá será algo muito próximo ao MVU , embora não tão totalmente integrado quanto um MVU tradicional como Elm/Fabulous. Talvez você possa ocultar as visualizações MAUI por trás da estrutura MVU, como o Fabulous faz com o Xamarin.Forms?

Não tenho certeza de como você implementaria um padrão MVC ou MVP em MAUI. Como um primeiro passo, estou pensando que talvez você tenha criado uma classe separada que exponha "ações" à função de exibição. Por exemplo, digamos que você tenha uma caixa de diálogo de confirmação MAUI e sua classe "controller" tenha um método "ClickOK" e um método "ClickCancel". A exibição MAUI encaminharia eventos de clique da exibição para o controlador, o que geraria um novo modelo ou alteraria o modelo existente.

@JeroMiya Concordo, definitivamente usar o padrão Redux pode torná-lo mais próximo do MVU e mantém a arquitetura muito menos opinativa. Eu sou um usuário feliz de React-Redux, React-Hooks, ReactiveX e ultimamente para Blazor Apps :heart: Fluxor :heart: . @mrpmorris pode contribuir com essa conversa.

Aqui está minha tentativa de um exemplo C#. Eu não tenho MAUI disponível para tentar isso como um exemplo real. Não há prévia, não é? De qualquer forma, esta é uma tradução aproximada da ideia.

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);

Isso incorreria em um custo de desempenho maior para atualizações do que no exemplo da Microsoft? Nesse modelo, se eu entendi, uma nova visão seria instanciada contendo todos os elementos da interface do usuário, em oposição a, na amostra MS, deixando os elementos de visão existentes no lugar e apenas atualizando o valor do rótulo (incorrendo em qualquer re -custo de dimensionamento que isso poderia ter).

Essa diferença parece ser uma das principais diferenças que impulsionam essa discussão em torno da nomenclatura e, portanto, estou curioso para saber se na arquitetura MVU tradicionalmente definida existem outras técnicas para atualizar a interface do usuário com eficiência e, em caso afirmativo, elas são implementadas no nível do motor de renderização?

@markmccaigue em relação ao desempenho: geralmente os sistemas MVU vêm com uma visualização virtual (ou DOM virtual no caso de html) e um mecanismo de comparação. Então, depois de diferenciar o DOM com o DOM virtual, o framework só precisa aplicar um patch ao DOM. Isso geralmente é muito eficiente, especialmente se você trabalha com estruturas de dados imutáveis.

Olá!!

Vou encerrar este problema por enquanto. Eu gostaria de fazer disso uma discussão, mas o github não quer fazer isso funcionar :-/

Se alguém quiser continuar esta conversa, crie um item de discussão e faça referência a esse problema