Maui: MVU n'est peut-être pas ce que vous pensez qu'il est

Merci @aspnetde , j'espère que vous vous joindrez à nous alors que nous travaillons à la mise en œuvre de cette idée au cours des 18 prochains mois environ. Compte tenu de votre histoire avec MVU, je pense que vous aurez beaucoup à apporter.

Je pense qu'il est trop tôt pour dire que .NET MAUI est ou n'est pas MVU puisque nous ne l'avons pas encore construit . :)

Oui, nous avons un prototype. Oui, c'est inspiré de l'expérience Comet. Et oui, nous savons que l'on craint que ce que nous avons montré jusqu'à présent ne corresponde à la définition de tout le monde de MVU.

J'espère que nous pourrons collaborer ! Si ce que nous concevons et expédions mérite une étiquette différente, je suis d'accord que nous devrions lui en donner une.

Comment vous attendriez-vous à voir C# MVU dans .NET MAUI ?

Quelles nouvelles fonctionnalités linguistiques verriez-vous nécessaires, le cas échéant ?

Pourrions-nous/devrions-nous envisager d'intégrer Fabulous et/ou quels modèles est-il logique de rendre commun entre C# et F#, et qu'est-ce qui devrait être différent ?

Comment vous attendriez-vous à voir C# MVU dans .NET MAUI ?

Avez-vous déjà entendu quelqu'un dire C# MVC ou C# MVVM ? _Model-View-Update_ aka _The Elm Architecture_ est un modèle architectural bien défini, pas une implémentation dépendante du langage.

Quelles nouvelles fonctionnalités linguistiques verriez-vous nécessaires, le cas échéant ?

• Alors que les types d'union aideraient à simplifier massivement la définition des messages, cela peut être fait via des interfaces/classes abstraites et une sous-classe par message, bien que cela nécessite un peu plus de code passe-partout à écrire.
• Afin de traiter les messages, la correspondance de modèle est utile si elle n'est pas requise. Je pense que l'état actuel des expressions de commutateur C# est déjà assez bon pour cela, car la forme des messages sera simple.
• Enfin, la caractéristique la plus importante que je vois est l'immuabilité par défaut et permet les comparaisons d'égalité structurelle. Autant que je me souvienne de la proposition actuelle d'enregistrements en C# 9 (alias classes de données), ceux-ci fourniront exactement cela.

Ainsi, C# 9 serait, tout en étant plus bruyant que F#, serait une bonne solution de mon point de vue actuel.

Pourrions-nous/devrions-nous envisager d'intégrer Fabulous et/ou quels modèles est-il logique de rendre commun entre C# et F#, et qu'est-ce qui devrait être différent ?

Comme indiqué ci-dessus, il ne devrait pas y avoir de spécificité linguistique dans l'approche globale, car MVU lui-même n'est que le style architectural ou le modèle d'application comme vous l'appelez.

@TimLariviere A propositions pour faire avancer Fabulous , qui comprend également des idées autour d'un DSL plus proche de SwiftUI. Vous voudrez peut-être y jeter un œil et/ou vous y engager aussi.

Au fait : j'ai fait une comparaison 1:1 de XF + C# + MVVM et XF + F# + MVU l'année dernière, les résultats peuvent être trouvés ici – y compris le code source.

Je pense qu'il est trop tôt pour dire que .NET MAUI est ou n'est pas MVU

Il ne s'agit pas de savoir si MAUI sera finalement MVU. Il s'agit de l'échantillon du blog d'annonce qui a déjà soulevé tant de confusion dans la communauté. Fondamentalement, je dois supposer que les auteurs n'ont pas encore vraiment examiné MVU. Parler de "C# MVU" n'améliore pas les choses.

Je suis d'accord avec @aspnetde et @forki le problème ici réside dans la communication.

Je pense qu'aucun de nous n'argumente pour abandonner ou modifier le DSL C# inspiré de la comète pour MAUI/XF, mais même si nous prenons ce qui est fait jusqu'à présent, cela utilise toujours le concept de liaison souligné qui fait partie du modèle MVVM .

C'est quelque chose que j'ai demandé maintes et maintes fois dans la communication directe et aussi dans les problèmes, c'est peut-être une bonne idée pour toutes les personnes impliquées de lire sur différents modèles comme MVVM et MVU.

Cela étant dit, il existe même un moyen d'implémenter MVU au-dessus de MVVM, mais la question reste de savoir quel problème cela résoudrait.

Avez-vous déjà entendu quelqu'un dire C# MVC ou C# MVVM ?

Oui, je comprends qu'il soit étrange de dire C# ou XAML suivi d'un modèle architectural comme MVVM ou MVU. Parmi la communauté plus large de développeurs avec qui je parle, il est nécessaire de préciser que vous pouvez utiliser n'importe quel nombre de combinaisons au sein de votre projet. L'intention n'est pas de dire qu'un "C# MVVM" est architecturalement différent de "XAML MVVM", mais que la combinaison est possible et que l'expérience du développeur dans son ensemble est donc légèrement différente.

Je pensais que ce fil pourrait discuter de l'apparence de MVU dans .NET MAUI, mais la discussion la plus productive ici est peut-être de savoir comment nous parlons de plusieurs expériences de développeur et de modèles d'architecture au sein d'un seul produit ?

Il semble que c'est la direction de la plupart des commentaires ici, vouloir discuter de ce que nous appelons et étiquetons les choses et comment nous utilisons les termes. J'aimerais beaucoup votre contribution à ce sujet, car je fais une grande partie de la communication et je veux m'assurer que j'ajoute effectivement de la clarté et ne génère pas de confusion.

Il s'agit de l'échantillon du blog d'annonce qui a déjà soulevé tant de confusion dans la communauté.

C'était ma contribution au blog et je m'excuse pour la confusion que cela a créé pour vous. J'ai mal calculé cela en ajoutant des liens vers le blog d'Elm et @aspnetde que nous disions "c'est ce qu'est MVU", et je n'avais pas prévu le poids que l'extrait de code aurait pour ceux d'entre vous qui ont une expérience et des attentes existantes en matière de MVU. à quoi cela ressemblerait/devrait ressembler ici.

Fondamentalement, je dois supposer que les auteurs n'ont pas encore vraiment examiné MVU.

Nous avons eu une conversation et un débat approfondis sur le sujet. S'il vous plaît ne présumez pas, et j'essaierai de ne pas le faire aussi.

la question demeure quel problème cela résoudrait.

@dersia le problème général à résoudre est de donner le choix aux développeurs. Si vous demandez ce que MVU au-dessus de MVVM résout, je n'en ai aucune idée - ce n'est pas quelque chose qui est demandé ou quelque chose que nous essayons de faire.

La refactorisation proposée dans les #28 et #66 consiste en partie à séparer les éléments spécifiques à la liaison de données et à MVVM des implémentations du moteur de rendu, de sorte que si vous optez pour MVU, vous n'utiliserez pas de fonctionnalités supplémentaires utilisées dans MVVM.

Je n'avais pas prévu le poids que supporterait l'extrait de code

Mais c'est la viande, non ? Et je suis désolé qu'il ne corresponde pas à l'étiquette.

@davidortinau

Il semble que c'est la direction de la plupart des commentaires ici, vouloir discuter de ce que nous appelons et étiquetons les choses et comment nous utilisons les termes. J'aimerais beaucoup votre contribution à ce sujet, car je fais une grande partie de la communication et je veux m'assurer que j'ajoute effectivement de la clarté et ne génère pas de confusion.

Je ne sais pas ce qu'il reste à ajouter de mon côté. Je pense avoir exprimé haut et fort ma position :-). Si vous allez implémenter MVU, vous pousserez une porte ouverte. Si c'est ce que l'on peut supposer en regardant l'extrait dans le message d'annonce et le référentiel Comet, n'hésitez pas à le faire - mais _veuillez_ arrêter de l'appeler MVU.

Merci.

Comme Don a été mentionné dans ce fil :-) - CC: @dsyme

Je ne comprends pas pourquoi cela s'appelle MVU, alors que ce n'est pas le cas. Cela pourrait être un excellent paradigme et fonctionner parfaitement ici - pourquoi ne pas trouver un terme approprié qui corresponde au paradigme et ne prête pas à confusion ?

@aspnetde qu'est-ce qu'il vous reste ? Beaucoup je suppose :).
J'ai lu certaines parties de votre thèse. Je dois dire que j'ai aimé. J'ai aussi lu le livre de Don Syme sur le F#. J'aime la programmation fonctionnelle. D'après mon expérience, c'est concis, mais difficile à saisir (comprendre). La lisibilité est une partie très importante du cycle de vie du développement. Beaucoup de temps est en fait consacré à la lecture du code. Et la récursivité est en écriture seulement. Vous pouvez l'écrire une fois, mais presque personne ne peut le lire (de la même manière que regexp).
Dans le passé, j'ai essayé Redux avec Angular pendant mon temps de prototypage/recherche dans l'entreprise. Est-ce une approche à moitié elme ? Ce fut une expérience précieuse. J'ai appris que je dois faire attention à ne pas muter l'état, et par conséquent je n'aurai pas à me souvenir de toute la pile, où exactement l'état peut changer soudainement.
Je comprends les avantages de l'immutabilité, mais j'ai vu une présentation avec Erik Meijer qui a soudainement déchiré une tête d'ours en peluche, pour nous montrer que le monde réel est mutable.

Alors ce que je voudrais souligner : notre pensée naturelle n'est-elle pas contre ces paradigmes ? Quelle est votre expérience ?

J'ai beaucoup d'expérience avec XAML/C#/MVVM, donc je me demande pourquoi Don Syme considère XAML comme inutile.
D'après mon expérience, cela aide à séparer les préoccupations (UI, présentation, logique commerciale, etc.). Je ne suis pas vraiment sûr que ces DSL (balisages C#) et MVU contribuent à améliorer la qualité du code à long terme. Les développeurs non expérimentés/indifférents mélangeront les responsabilités. J'ai également besoin de plus d'expérience avec le modèle MVU pour le comprendre correctement, mais vous avez essayé ces deux paradigmes et c'est très précieux pour toute la communauté.
Merci de partager autant que vous le pouvez. Merci @aspnetde !

Merci (à tous) de votre compréhension

@davidortinau peut-être qu'il y a eu un malentendu ici, je suis totalement pour le choix et je laisse à chacun le

Miss communication La mauvaise
Dans ce cas, je pense que l'utilisation d'une mauvaise formulation doit être corrigée et pour que cela se produise, j'aimerais que ce projet
a) comprenez que MVU n'est pas le bon nom pour ce dont nous parlons ici
et b) pour trouver le terme juste pour décrire ce que nous essayons d'établir ici
puis c) mettre à jour tout le monde et commencer à utiliser ce nouveau nom

Je pense que nous sommes encore à un point où nous pouvons encore revenir en arrière et le réparer. Faisons-le bien, la pire chose qui puisse arriver est que la communauté XF/Maui comprend MVU comme autre chose que le reste du monde.

Cela étant dit, je suis un grand fan de MVU et j'aime aussi MVVM, et je pense que l'approche fluide de MVVM (je n'ai pas encore de meilleur nom) comme dans Comet et ce qui a été présenté jusqu'à présent est génial et aide un beaucoup de développeurs et je le soutiendrai, je pense juste que nous devrions corriger le nom.

Edit : miss communication a abandonné le concours.

Je comprends les avantages de l'immuabilité, mais j'ai vu une présentation avec Erik Meijer qui a soudainement déchiqueté une tête d'ours en peluche, pour nous montrer que le monde réel est mutable.

@tomasfabian c'est faux.

Vous devez commencer à voir le monde comme une série d'événements, c'est ce qu'il est en réalité (non, je ne veux pas lancer une discussion sur la recherche d'événements ici).
Ce qui est arrivé à l'ours en peluche, c'est seulement qu'un nouvel événement a été ajouté à son état, l'événement dans ce cas est « arraché de la tête ». Et comme vous pouvez le réaliser, une fois qu'un événement s'est produit, vous ne pouvez pas revenir en arrière, car vous ne pouvez pas simplement annuler ou supprimer ce qui se passe. Pour remettre la tête sur le nounours, vous auriez besoin d'un nouvel événement appelé "tête cousue sur le corps". ??

Discuter des avantages ou non de FP et MVU est hors sujet à mon humble avis ici. Ce problème était, pensais-je, juste à propos du potentiel de mauvaise communication et de nommage précis.

@isaacabraham vous avez peut-être raison, et je m'en excuse. C'est de ma faute. Je sais qu'il est important de nommer les choses, mais d'un autre côté, le titre du numéro est « MVU n'est peut-être pas ce que vous pensez qu'il est ». Il s'agit donc, espérons-le, d'un sujet un peu plus vaste que de nommer des choses.
Merci Tomas

@tomasfabian Je serais super heureux de discuter avec vous des avantages et des inconvénients de MVU, FP ou autre, réel ou imaginaire 😊 Ne pensez pas que c'est le forum approprié pour cela.

@davidortinau
En ce qui concerne les fonctionnalités de langage et les changements d'architecture qui seraient utiles, j'espère pouvoir contribuer avec quelques suggestions :

* Le mot-clé new et autres bruits syntaxiques.
Contrairement à Dart ou Kotlin, C# est probablement bloqué avec un mot-clé new obligatoire using static en haut de nos fichiers .cs de code de vue, puis appeler les méthodes sans le bruit syntaxique de new . Cela réduirait un peu l'encombrement et le bruit des fonctions d'affichage C#. Bien sûr, ces wrappers de constructeur de méthode statique pourraient être générés automatiquement par la communauté (j'ai fait quelque chose de similaire pour Xamarin.Forms à utiliser avec CSharpForMarkup), mais ce serait bien d'avoir un ensemble dans la boîte d'entre eux maintenu par le projet MAUI.

De plus, toute proposition de langage C# qui aiderait à réduire l'encombrement ou le bruit syntaxique dans les grands arbres d'expression (comme cela est courant dans les fonctions d'affichage MVU/Comet/CSharpForMarkup) aiderait grandement. C#9 a parcouru un LONG chemin à cet égard pour améliorer les parties M et U de MVU, mais la partie V est toujours un point sensible en termes de syntaxe.

* Propriétés de l'extension *
Je sais que la proposition "extension-everything" est en attente pour le moment, mais une chose qui pourrait être utile pour MVVM-with-C#-markup (par exemple CSharpForMarkup avec Xamarin.Forms), serait les propriétés d'extension. Avec CSharpForMarkup, chaque assistant devait être implémenté à l'aide d'une méthode d'extension, mais dans certains cas, une propriété d'extension (utilisable dans l'initialiseur d'objet) aurait une bien meilleure apparence :

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

Cela ne s'applique vraiment qu'aux arborescences d'objets de vue mutables, comme dans MVVM avec C# pour le balisage. Pour le MVU ou d'autres architectures d'interface utilisateur fonctionnelles, cela ne s'applique pas car les objets de vue sont immuables. Dans ces cas, une méthode d'extension fluide est encore plus appropriée.

* Soyez moins opiniâtre (ou de bas niveau si vous préférez) sur la gestion de l'État *
Je pense que l'une des plus grandes barrières à l'entrée pour implémenter MVU sur Xamarin.Forms était le manque de deux composants essentiels : le graphe d'objet léger que les fonctions de vue pourraient retourner, que le framework pourrait « restituer » en composants réels (avec leur représentations spécifiques à la plateforme, etc...). Et la deuxième pièce est un moteur de différence qui met à jour efficacement les vues spécifiques à la plate-forme lourde en recherchant les différences entre une valeur de retour d'une fonction de vue et une autre, y compris un moyen de faire des différences efficacement en faisant des différences partielles, etc...

On dirait que MAUI fournit maintenant ces deux pièces essentielles, ce qui est génial ! Cependant, il semble, au moins en surface, être très étroitement lié à une manière opiniâtre de gérer l'état qui, selon certains membres de la communauté MVU, est plus proche de MVVM que de MVU ou d'architectures d'interface utilisateur « fonctionnelles » similaires. Je pense que ma préférence serait de conserver les deux éléments essentiels que j'ai mentionnés ci-dessus (graphique d'objet de vue léger et moteur de différence efficace), et de les marier avec un système de composants de niveau inférieur sur lequel MVU ou Comet pourraient être efficacement superposés, selon le développeur choix. C'est peut-être déjà le but, et je ne le vois pas ? Si c'est le cas, j'aimerais voir plus de discussions à ce sujet avec au moins quelques exemples de base.

@aspnetde pourquoi as-tu supprimé ton message ?

@tomasfabian

D'après mon expérience, [MVVM] aide à séparer les préoccupations (interface utilisateur, présentation, logique commerciale, etc.)

Oui. J'ai fait de bonnes expériences avec les grandes applications Xamarin.iOS et Xamarin.Android construites avec MvvmCross. Bien que je préfère de loin les bibliothèques aux frameworks aujourd'hui, je pense que tous ces projets (certains avec une LOC à six chiffres) ont été un succès, tant du point de vue technique que commercial.

Je pense que MVVM fait particulièrement du bon travail lorsqu'il s'agit de faire évoluer une application. Surtout dans le mobile, où nous sommes obligés d'expédier des monolithes, cela nous a aidé à refactoriser nos applications en modules indépendants après avoir dépassé une certaine taille.

Notre pensée naturelle n'est-elle pas contre ces paradigmes ([MVU]) ? Quelle est votre expérience ?

Je ne pense pas. Profitez de votre expérience avec Redux pour le stockage et imaginez l'ensemble de votre application pour bénéficier de ses avantages. Bien qu'il semble être plus complexe à première vue, d'après mon expérience, il est beaucoup plus simple à comprendre et à utiliser. Comme @forki le souligne souvent, c'est presque ennuyeux car le flux de données unidirectionnel indique clairement ce qui se passe tout le temps.

Je ne suis pas vraiment sûr que ces DSL (balisages C#) et MVU contribuent à améliorer la qualité du code à long terme.

Bien que MVU et MVVM présentent des avantages différents, les deux ont également des inconvénients différents.

Malgré le succès de nos projets MVVM, mon équipe et moi avons perdu quelques cheveux à les déboguer. Dans un projet en particulier, nous avons commencé à souffrir d'une complexité causée par le manque d'expérience des nouveaux membres de l'équipe et des malentendus – comme vous l'avez déjà souligné. Je pense que c'est moins probable dans MVU lorsqu'il est appliqué strictement, car il définit les limites de la façon dont les choses fonctionnent si étroitement, qu'il est presque plus difficile de sortir de cela et de construire les choses de la mauvaise manière, que l'inverse.

Pour MVU, je vois deux problèmes majeurs. Premièrement : la mise à l'échelle. Beaucoup préconisent un programme unique. Je suis sceptique ici (et je pense que plusieurs programmes/modules seraient un meilleur moyen). Deuxièmement : à l'heure actuelle, une chose comme Fabulous se trouve au-dessus de Xamarin.Forms. C'est donc une couche d'abstraction au-dessus d'une couche d'abstraction au-dessus d'une couche d'abstraction au-dessus d'iOS/Android. C'est une énorme complexité. Ainsi, non seulement vous traitez des bogues non résolus dont personne ne se soucie, mais c'est aussi un travail plus ou moins fastidieux et désagréable de mettre à jour une couche d'abstraction (Fabulous) lorsque l'autre (Xamarin.Forms) change.

C'est là que je verrais une grande chance pour MAUI. Honnêtement, j'aimerais voir les responsables de Fabulous s'associer à Microsoft ici. Et j'espère vraiment que Microsoft ne le gâchera pas, comme d'autres parties de l'organisation l'ont fait dans le passé.

Thomas

Lorsque je lisais l' annonce officielle l'autre jour, j'ai été surpris de ce qui y était présenté comme 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 ce qui me concerne, ce n'est pas MVU . J'ai déjà écrit quelques réflexions sur les raisons pour lesquelles je pense ainsi ici .

Don Syme, qui, si j'ai bien compris, a passé plusieurs mois de 2018 à implémenter MVU sur Xamarin.Forms et à construire ce qui est devenu plus tard Fabulous , est un peu plus diplomate , mais le résultat est le même.

Alors, quel est mon point?

• J'aimerais que vous implémentiez le vrai modèle architectural, que ce soit en C# ou en F#. Atteindre les personnes derrière Fabulous pourrait être un début ici.
• Si cela ne vous intéresse pas, mais que vous avez une vision claire de la création de ce qui est disponible aujourd'hui en tant que bibliothèque Comet , envisagez d'utiliser un nom plus approprié pour ce "modèle d'application". Inventez quelque chose de nouveau. Nommez-le MSMVU. Peu importe. Mais ne vendez pas de pommes pour des oranges.

Acclamations!

Pourquoi l'appelleraient-ils MSMVU ? Comet a été MVU, et il le restera. Et Maui est un MVU.

Je pense qu'il est trop tôt pour dire que .NET MAUI est ou n'est pas MVU

Il ne s'agit pas de savoir si MAUI sera finalement MVU. Il s'agit de l'échantillon du blog d'annonce qui a déjà soulevé tant de confusion dans la communauté. Fondamentalement, je dois supposer que les auteurs n'ont pas encore vraiment examiné MVU. Parler de "C# MVU" n'améliore pas les choses.

Cela ne crée aucune confusion. Est-ce juste que certaines personnes ne peuvent pas le supporter en voyant C# faire MVU.

Pour ce que ça vaut, SwiftUI (dont Comet s'inspire en grande partie) a tendance à appeler son modèle MVVM, même s'il n'y a pas de directives explicites.
Je n'ai trouvé aucune mention de MVU cependant.

@TimLariviere https://github.com/Clancey/Comet#key -concepts
Fondamentalement, Comet l'appelait MVU et manquait déjà le point de la boucle de message que nous avons dans les anciennes définitions de MVU

Pour ce que ça vaut, SwiftUI (dont Comet s'inspire en grande partie) a tendance à appeler son modèle MVVM, même s'il n'y a pas de directives explicites.

Ce n'est même pas faux, en regardant l'exemple au début de ce post ici : https://nalexn.github.io/clean-architecture-swiftui/

Je n'ai trouvé aucune mention de MVU cependant.

Le même article en parle également brièvement (en tant que combinaison de SwiftUI + Redux = TEA). Bien qu'il prenne alors une étrange tournure vers "Clean Architecture" 😄

Puisque j'ai été mentionné ici, je vais juste dire quelques choses.

• Je pense que MAUI est génial et je pense que l'apprentissage de MVU en tant qu'architecture peut être utile pour que les gens comprennent MAUI.

• Il est facile de s'accrocher aux mots, et nous devrions probablement tous prendre une pause et essayer de ne pas nous en soucier à ce stade, car il y a beaucoup de temps pour ajuster les mots qui sont utilisés et je pense que le message concernant une terminologie précise a été entendu. Personnellement, je pense qu'Elm a établi que l'utilisation sans fioritures et sans réserve de "MVU" signifie des messages explicites, une mise à jour explicite, des modèles fonctionnels, un recalcul de la vue fonctionnelle et une mise à jour différentielle. Mais il existe de nombreuses variantes de MVU et MAUI est un point de ce spectre (qui couvre tout le chemin jusqu'à MVVM en tant que sorte de système de traitement de messages incrémenté manuellement avec un état mutable implicite et omniprésent). La communication SwiftUI est intéressante de ce point de vue.

• Je remarque que les gens ont tendance à avoir des croyances et des opinions très fortes dans ce domaine et peuvent prendre les choses très personnellement. Je sais ce que c'est, et comme la conception d'un langage de programmation, je pense que tous les points de l'espace ont des avantages et des inconvénients. J'encourage tout le monde à essayer, utiliser, apprendre, partager et travailler ensemble pour créer la meilleure gamme de technologies possible.

@dsyme
Je pense que le terme approprié pour l'architecture Comet/MAUI est une variation du flux de données unidirectionnel (ou UDF), mais pas MVU car MVU est lui-même une variation très spécifique de l'UDF. MAUI/Comet est certainement qualifié de framework UDF (comme SwiftUI), mais il n'est pas qualifié de framework MVU. Il existe plusieurs variantes d'UDF dont MVU, Flux, Redux, React, etc... mais c'est un malentendu d'appeler Comet MVU alors que ce n'est pas du tout MVU.

Contrairement à MVU, le modèle est mutable et muté par le code de la fonction View. Des mutations sont ensuite observées et les vues réagissent à ces mutations par un nouveau rendu. C'est toujours unidirectionnel car les vues ne sont pas mutées, mais il n'y a pas de fonction de mise à jour, pas de messages et pas de distribution de messages - donc pas de MVU. C'est plus proche d'une variation unidirectionnelle de MVVM.

@JeroMiya Merci, avez-vous une référence pour cette terminologie ?

@dsyme Je n'ai pas de référence spécifique pour cela, mais j'ai commencé à entendre le terme utilisé au début de React, en particulier en référence à React lui-même et à quelques-uns des premiers modèles qui ont émergé tels que Redux et Flux. Je me souviens d'un article qui décrivait un certain nombre de variantes UDF (principalement dans l'espace React), mais je ne le trouve pas maintenant.

Cela étant dit, ce n'est pas une architecture formelle - plus comme le concept de base de la vue étant une fonction du modèle, par opposition à la vue étant un arbre d'objets avec état qui mute en réponse à des événements. Le concept UDF ne spécifie pas nécessairement comment le modèle est mis à jour ou s'il est mutable ou immuable. MVU étend le concept UDF non seulement à la vue elle-même, mais également au processus de mise à jour du modèle. Ainsi, dans MVU, le modèle est également immuable et les changements d'état de l'interface utilisateur sont représentés sous forme de commandes qui produisent de nouveaux modèles, qui déclenchent de nouvelles vues.

Ce n'est bien sûr pas un nouveau concept - même avant React, la plupart des frameworks Web côté serveur comme Asp.Net MVC, Rails, même PHP comptent techniquement comme unidirectionnels. Ce n'était tout simplement pas courant pour les frameworks SPA traditionnels et les frameworks d'interface utilisateur côté client avant l'arrivée de React.

@dsyme Je n'ai pas de référence spécifique pour cela, mais j'ai commencé à entendre le terme utilisé au début de React, en particulier en référence à React lui-même et à quelques-uns des premiers modèles qui ont émergé tels que Redux et Flux. Je me souviens d'un article qui décrivait un certain nombre de variantes UDF (principalement dans l'espace React), mais je ne le trouve pas maintenant.

Cela étant dit, ce n'est pas une architecture formelle - plus comme le concept de base de la vue étant une fonction du modèle, par opposition à la vue étant un arbre d'objets avec état qui mute en réponse à des événements. Le concept UDF ne spécifie pas nécessairement comment le modèle est mis à jour ou s'il est mutable ou immuable. MVU étend le concept UDF non seulement à la vue elle-même, mais également au processus de mise à jour du modèle. Ainsi, dans MVU, le modèle est également immuable et les changements d'état de l'interface utilisateur sont représentés sous forme de commandes qui produisent de nouveaux modèles, qui déclenchent de nouvelles vues.

Ce n'est bien sûr pas un nouveau concept - même avant React, la plupart des frameworks Web côté serveur comme Asp.Net MVC, Rails, même PHP comptent techniquement comme unidirectionnels. Ce n'était tout simplement pas courant pour les frameworks SPA traditionnels et les frameworks d'interface utilisateur côté client avant l'arrivée de React.

@JeroMiya merci pour cela, c'est exactement comme ça que je comprends MVU.
Je dirais même que l'une des applications les plus anciennes et encore les plus utilisées qui utilise et illustre MVU dans sa meilleure forme est MS Excel.

@dsyme en lisant vos commentaires, j'ai l'impression que vous faites référence à MAUI comme terme pour l'architecture discutée (CSharpForMarkup avec MVVM).
Veuillez me préciser que ce n'est pas ce que vous comprenez comme MAUI ou si c'est le cas.
D'après ce que je comprends, MAUI n'est que le prochain cadre d'application MS à remplacer XF à l'avenir.

J'aime vraiment la façon dont ce problème et ses commentaires évoluent. Merci pour tout le monde participant. Peut-être qu'ensemble, nous pouvons établir et nommer correctement toutes les architectures différentes en tant que saveurs possibles pour MAUI.

@dersia Merci ! Juste une note de ma propre expérience avec CSharpForMarkup : c'est un niveau un peu inférieur à celui de MVVM - plus un ensemble de méthodes d'extension et d'utilitaires pour rendre le balisage C# plus rationalisé et plus agréable. Vous pouvez certainement implémenter un modèle MVVM avec lui car il a des aides pour faciliter les liaisons ViewModel, mais ce que j'ai fini par faire, c'est d'implémenter toute ma logique de vue dans Redux au lieu de ViewModels. Juste besoin d'ajouter quelques méthodes d'extension pour lier les propriétés de vue aux sélecteurs d'état, qui ne sont que Func<StateType, ChildStateType> je passe aux opérateurs Select et DistinctUntilChanged sur le magasin d'état Redux, qui est un Observable<StateType> . Flux de données pas tout à fait unidirectionnel, mais je n'avais pas une méthode mature pour faire des différences d'arborescence d'objets d'interface utilisateur et afficher des fonctions comme le fait Fabulous maintenant.

Il y a quelque temps, la police REST a essayé de nous enfoncer dans la gorge que nous ne devrions pas tous nous appeler REST. Tout le monde l'appelle encore REST aujourd'hui et nous sommes tous bien vivants. ??

@bitbonk, la communauté REST a abandonné le terme car il est devenu de plus en plus inutile à mesure que de plus en plus de choses étaient mélangées. Ils utilisent maintenant « hypermédia » pour désigner le transfert d'état de représentation. REST, aujourd'hui, ne signifie vraiment que « pas de SOAP » ou « JSON sur HTTP », dont aucun ne parvient à communiquer son idée de base. Les commentateurs ici espèrent éviter le même sort pour MVU.

@davidortinau @tomasfabian , je n'ai pas encore vu d'exemple de MVU sur MAUI. Je vais essayer de trouver un exemple ce soir. Je viens de faire quelque chose de similaire pour WinForms ici . Je suppose que ça ne devrait pas être trop dur.

@JeroMiya Merci, avez-vous une référence pour cette terminologie ?

@dsyme , je pense que cela vient de React Flux, mais ils ont indiqué des architectures de jeu, c'est-à-dire Doom 3. Je pense que je me souviens d'en avoir discuté avec @TIHan lors de sa première présentation.

• 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/unidirectionnel-data-flow

Voici ma tentative d'exemple en C#. Je n'ai pas MAUI disponible pour essayer ceci comme un exemple réel. Il n'y a pas d'aperçu, n'est-ce pas ? Quoi qu'il en soit, c'est une traduction approximative de l'idée.

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

Une fois, j'ai brièvement essayé quelque chose de similaire , à l'exception de la partie vue. Avec l'arrivée de Records en C# 9, ce sera encore plus raisonnable.

Je suis relativement nouveau sur MVU et j'ai probablement très peu d'expérience de son utilisation par rapport à beaucoup d'entre vous. Mais les concepts MVU ont définitivement attiré mon intérêt, et j'en profite. Je suis très heureux de voir que les développeurs C# disposent d'un cadre pour les aider à développer le modèle MVU.

Je suis tout à fait d'accord pour dire que MAUI MVU n'est pas le MVU typique et qu'il a une énorme influence sur SwiftUI. Son auteur principal Clancey himeslef l'avait dit très clairement dans presque toutes ses séances. Nous savons tous que Redux est fortement influencé par MVU, tout comme SwiftUI, Flutter et de nombreux autres frameworks. Aucun d'entre eux n'est un pur MVU.

Mais je suis sûr que nous sommes tous d'accord pour dire que le modèle architectural le plus proche pour tous ces frameworks est MVU. C'est la raison pour laquelle les gens s'y réfèrent. Et rappelez-vous que nous parlons d'un titre de blog pour un framework qui sortira dans un an et demi.

Et si vous dites que les gens s'énervent pour ce titre de blog. Je ne pense pas que nous devrions vraiment nous inquiéter pour eux. La communauté doit encore continuer. Dépensons notre énergie pour améliorer ce cadre. Ne vous inquiétez pas trop des petits détails.

Mais je suis sûr que nous sommes tous d'accord pour dire que le modèle architectural le plus proche pour tous ces frameworks est MVU. C'est la raison pour laquelle les gens s'y réfèrent.

Chiens, chevaux, chats et chimpanzés sont tous très proches les uns des autres. À partir de maintenant, je les appellerai tous des chats.

:) Eh bien, vous n'êtes pas obligé. Mais laissez-moi vous dire quelque chose : les chats, les tigres, les léopards, etc. sont appelés chats. Et je suis content que vous l'ayez soulevé. Parce que c'est exactement le cas ici.

@aspnetde : Thomas, avec tout cela dit. Je dois dire que votre blog MVU original est l'un des meilleurs articles qui explique le concept de manière très claire et précise. J'en ai beaucoup appris. Merci

@ libin85 il y a exactement le problème. Vous avez commencé à énumérer les choses qui sont en fait dans une catégorie et ignoré celles qui ne le sont pas. En plaçant l'échantillon MAUI dans la catégorie MVU, vous placez essentiellement un chimpanzé dans la catégorie des chats.

Il y a des similitudes avec les implémentations MVU, comme une vue immuable. Mais il y a des différences claires comme, il n'y a pas de boucle de message et pas de fonction de mise à jour explicite. Le modèle est muté directement dans la vue. C'est quelque chose que les gens ne voulaient explicitement pas quand ils ont proposé MVU. Dans certaines langues, il serait même impossible de le faire - c'est pourquoi MVU a émergé. Et pourquoi il est devenu populaire. Maintenant, nous devons être prudents si nous supprimons ces propriétés de notre définition de MVU.

@forki : Je ne suis pas contre ce que vous avez dit. En fait, ce sont les points que vous avez soulevés dans le dernier commentaire dont nous devons discuter en tant que communauté et non le titre d'un article de blog. C'est mon point. C'est une chose positive à discuter et le cadre y gagnera.

Je suis d'accord que le nom est un petit détail qui ne doit pas détourner l'attention d'aspects plus importants. Cependant, la raison pour laquelle j'en ai parlé est que personnellement, je ne vois pas MAUI comme un effort communautaire où le bon sens mènera finalement à une solution convenue d'un commun accord. C'est un produit Microsoft où les décisions finales sont prises à huis clos. Je suis ici en ma qualité de client pour faire part de mes préoccupations.

Mais je suis sûr que nous sommes tous d'accord pour dire que le modèle architectural le plus proche pour tous ces frameworks est MVU.

@ libin85 Je ne suis pas d'accord, c'est le modèle architectural le plus proche. MVU est un ensemble de contraintes par rapport à ce qui ressemble plus généralement à MVP, ou Model View Presenter. MVVM est similaire, prenant une direction différente dans la mesure où son présentateur est un ViewModel avec des liaisons de données. MVP lui-même est une forme contrainte de MVC. Je pense qu'il est assez sûr de dire que ce sont tous des descendants de MVC et même de MVP, mais dire que MVU s'applique à SwiftUI, Flux, etc. revient à faire de MVU un terme dénué de sens.

Je suis d'accord que le nom est un petit détail qui ne doit pas détourner l'attention d'aspects plus importants.

Non, les noms sont importants. Ils sont difficiles, à la fois à établir et à retenir leur sens. Voir aussi REST, dont j'ai parlé ci-dessus. REST est tellement abusé qu'il n'a plus de sens que comme terme de jargon marketing. J'aimerais que cela n'arrive pas à MVU, en particulier lorsqu'il existe des termes pour ce que le "MVU" de MAUI fournit.

Pour ce que ça vaut, je pense que le MAUI "MVU" est une bonne alternative à l'option MVVM. Tout comme avec REST, vous n'avez pas besoin de faire quelque chose de définitionnel pour faire quelque chose d'utile et de bon. S'il vous plaît, ne brouillez pas le nom avec des alternatives qui s'écartent clairement d'un modèle bien défini et établi. Après tout, MVU serait _également_ une bonne alternative aux options MVVM et Comet.

Pour ce que ça vaut, je pense que le MAUI "MVU" est une bonne alternative à l'option MVVM. Tout comme avec REST, vous n'avez pas besoin de faire quelque chose de définitionnel pour faire quelque chose d'utile et de bon, veuillez simplement ne pas brouiller le nom avec des alternatives qui s'écartent clairement de sa définition.

ACK COMPLET.

Pourquoi l'appelleraient-ils MSMVU ? Comet a été MVU, et il le restera. Et Maui est un MVU.

@saint4eva ils sont "commercialisés" en tant que, mais par définition pas, MVU.

Je suis d'accord que le nom est un petit détail qui ne doit pas détourner l'attention d'aspects plus importants.

Non, les noms sont importants. Ils sont difficiles, à la fois à établir et à retenir leur sens. Voir aussi REST, dont j'ai parlé ci-dessus. REST est tellement abusé qu'il n'a plus de sens que comme terme de jargon marketing. J'aimerais que cela n'arrive pas à MVU, en particulier lorsqu'il existe des termes pour ce que le "MVU" de MAUI fournit.

Pour ce que ça vaut, je pense que le MAUI "MVU" est une bonne alternative à l'option MVVM. Tout comme avec REST, vous n'avez pas besoin de faire quelque chose de définitionnel pour faire quelque chose d'utile et de bon. S'il vous plaît, ne brouillez pas le nom avec des alternatives qui s'écartent clairement d'un modèle bien défini et établi. Après tout, MVU serait _également_ une bonne alternative aux options MVVM et Comet.

Je suis d'accord avec la plupart de ce que vous avez dit, mais je pense que "Maui MVU" est toujours aussi mauvais et déroutant. J'irais probablement avec "Maui MVP" ou MVC. Les deux fonctionnent et sont plus proches de ce qui est présenté dans le billet de blog que MVU.

Modifier ajouter :
Je ne sais même pas où réside la version proposée. Je veux dire que la logique dans MVVM réside dans le ViewModel, avec MVU, elle réside dans la fonction de mise à jour et avec MVP, elle réside dans le présentateur et avec MVC, elle réside dans le contrôleur.

Y aura-t-il une Vue où tout habite ? Ou est-ce que tout vit dans une classe nommée par le modèle de domaine qui sert la vue, la logique et le modèle ? Les modèles sont-ils censés être des classes (types) ou des enregistrements séparés ?

Je pense que c'est pour moi le principal problème ici, je n'ai aucune idée de comment il est "présenté" et par conséquent, je ne vois pas qu'il y ait une fonction de mise à jour, de modèle et de vue.

Hors de la boîte, il me semble que MAUI est un peu plus bas que les modèles discutés jusqu'à présent - vraiment juste le modèle (ou l'état) et la partie Vue de ces autres modèles. Quelque chose sur lequel vous pourriez peut-être vous appuyer pour mettre en œuvre ces autres modèles (bien que la gestion de l'état soit un peu opiniâtre).

Ainsi, par exemple, si le T dans State<T> est une classe de type ViewModel et que vous ajoutez un ensemble distinct de classes de modèle de données, vous obtiendrez quelque chose comme MVVM avec une vue unidirectionnelle.

D'un autre côté, si vous ajoutez un système de gestion d'état de type Redux et branchez le modèle d'état Redux en tant que votre T dans State<T> , alors vous obtenez quelque chose de très proche de MVU , bien que pas aussi complètement intégré qu'un MVU traditionnel comme Elm/Fabulous. Peut-être pourriez-vous masquer les vues MAUI derrière le framework MVU, comme le fait Fabulous avec Xamarin.Forms ?

Je ne sais pas comment implémenter un modèle MVC ou MVP sur MAUI. En guise de premier passage approximatif, je pense peut-être que si vous créez une classe distincte qui expose des "actions" à la fonction d'affichage. Par exemple, supposons que vous ayez une boîte de dialogue de confirmation MAUI et que votre classe "contrôleur" ait une méthode "ClickOK" et une méthode "ClickCancel". La vue MAUI transmettrait les événements de clic de la vue au contrôleur, ce qui générerait soit un nouveau modèle, soit une mutation du modèle existant.

@JeroMiya Je suis d'accord, l'utilisation du modèle Redux peut le rapprocher de MVU et garder l'architecture beaucoup moins d'opinion. Je suis un utilisateur heureux de React-Redux, React-Hooks, ReactiveX et dernièrement des applications Blazor :heart: Fluxor :heart: . @mrpmorris peut contribuer à cette conversation.

Voici ma tentative d'exemple en C#. Je n'ai pas MAUI disponible pour essayer ceci comme un exemple réel. Il n'y a pas d'aperçu, n'est-ce pas ? Quoi qu'il en soit, c'est une traduction approximative de l'idée.

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

Cela entraînerait-il un coût de performances plus important pour les mises à jour que dans l'exemple Microsoft ? Dans ce modèle, si je comprends bien, une nouvelle vue serait instanciée contenant tous les éléments de l'interface utilisateur, par opposition à, dans l'échantillon MS, laissant les éléments de vue existants en place et mettant simplement à jour la valeur de l'étiquette -le coût de dimensionnement que cela pourrait avoir).

Cette différence semble être l'une des principales différences à l'origine de cette discussion sur le nommage, et je suis donc curieux de savoir si dans l'architecture MVU traditionnellement définie, il existe d'autres techniques pour mettre à jour efficacement l'interface utilisateur, et si oui, sont-elles implémentées au niveau du moteur de rendu ?

@markmccaigue en ce qui concerne les performances : les systèmes MVU sont souvent livrés avec une vue virtuelle (ou un DOM virtuel dans le cas de html) et un moteur de comparaison. Ainsi, après avoir différencié le DOM avec le DOM virtuel, le framework n'a besoin que d'appliquer un correctif au DOM. C'est généralement très très efficace, surtout si vous travaillez avec des structures de données immuables.

Bonjour!!

Je vais fermer ce problème pour le moment.. J'aimerais en faire une discussion mais github ne veut pas que cela fonctionne :-/

Si quelqu'un souhaite poursuivre cette conversation, veuillez créer un élément de discussion, puis faire référence à ce problème.