Maui: MVUはあなたが思っているものではないかもしれません

@aspnetdeに感謝します。今後18か月ほどでこのアイデアの実装に取り​​組んでいますので、ぜひご参加ください。 MVUでのあなたの歴史を考えると、私はあなたが貢献することがたくさんあることを期待しています。

.NET MAUIはまだ実際に構築されていないため、MVUであるかどうかを判断するのは時期尚早だと思います。 :)

はい、プロトタイプがあります。 はい、それは彗星の実験に触発されています。 そして、はい、これまでに示したことが、MVUのすべての人の定義と一致しないという懸念があることを私たちは知っています。

コラボレーションできることを願っています！ 私たちが最終的に設計して出荷するものが別のラベルに値する場合、私はそれに1つを与えるべきであることに同意します。

.NET MAUIでC＃MVUをどのように見ると思いますか？

もしあれば、どのような新しい言語機能が必要だと思いますか？

Fabulousの統合を検討できますか、および/またはC＃とF＃の間で共通にするのはどのようなパターンが理にかなっていますか？

.NET MAUIでC＃MVUをどのように見ると思いますか？

C＃MVCまたはC＃MVVMと言っている人を聞いたことがありますか？ _Model-View-Update_別名_TheElm Architecture_は、言語に依存する実装ではなく、明確に定義されたアーキテクチャパターンです。

もしあれば、どのような新しい言語機能が必要だと思いますか？

• 共用体タイプはメッセージの定義を大幅に簡素化するのに役立ちますが、それはインターフェース/抽象クラスおよびメッセージごとのサブクラスを介して行うことができますが、それを書くにはもう少し定型的なコードが必要です。
• メッセージを処理するには、必要がなければパターンマッチングが役立ちます。 メッセージの形が単純になるので、C＃スイッチ式の現在の状態はすでにそれで十分だと思います。
• 最後になりましたが、私が目にする最も重要な機能は、デフォルトで不変性であり、構造的同等性の比較が可能になっていることです。 C＃9（別名データクラス）のレコードの現在の提案を覚えている限り、それらはまさにそれを提供します。

したがって、C＃9は、F＃よりもノイズが多いですが、私の現在の観点からは良いでしょう。

Fabulousの統合を検討できますか、および/またはC＃とF＃の間で共通にするのはどのようなパターンが理にかなっていますか？

上で書いたように、MVU自体は単なるアーキテクチャスタイルまたはアプリモデルであるため、全体的なアプローチに特に言語固有のものはありません。

@TimLariviere最近、 Fabulousを前進させるためのいくつかの

ちなみに、昨年XF + C＃+ MVVMとXF + F＃+ MVUを1：1で比較しましたが、結果はここにあります–ソースコードを含みます。

.NETMAUIがMVUであるかどうかを言うのは時期尚早だと思います

MAUIが最終的にMVUになるかどうかではありません。 これは、コミュニティですでに多くの混乱を引き起こしている発表ブログのサンプルに関するものです。 基本的に、著者はまだMVUを実際には調べていないと想定する必要があります。 「C＃MVU」について話しても、これは改善されません。

@aspnetdeと@forkiに同意します。ここでの問題は、コミュニケーションにあります。

私たちの誰もがMAUI / XF用の彗星に触発されたC＃DSLを削除または変更することを主張していないと思いますが、これまでに行われていることを採用しても、これはMVVMパターンの一部である下線付きのバインディングコンセプトを使用しています。

これは私が直接のコミュニケーションで何度も何度も質問していることであり、問​​題もあります。関係者全員がMVVMやMVUなどのさまざまなパターンを読むことをお勧めします。

そうは言っても、MVVMの上にMVUを実装する方法もありますが、それがどのような問題を解決するのかという疑問が残ります。

C＃MVCまたはC＃MVVMと言っている人を聞いたことがありますか？

はい、C＃またはXAMLの後にMVVMやMVUのようなアーキテクチャパターンが続くと言うのは奇妙だと思います。 私が話している開発者の幅広いコミュニティの中で、プロジェクト内で任意の数の組み合わせを利用できることを明確にする必要があります。 「C＃MVVM」が「XAMLMVVM」とアーキテクチャ的に異なると言うつもりはありませんが、組み合わせが可能であり、開発者のエクスペリエンス全体がわずかに異なるということです。

このスレッドでは、MVUが.NET MAUIでどのように表示されるかについて説明していると思いましたが、おそらくここでのより生産的な説明は、単一の製品内の複数の開発者エクスペリエンスとアーキテクチャパターンについて説明する方法です。

それがここでのほとんどのコメントの方向性であるように思われます。私たちが何と呼んでラベルを付け、用語をどのように使用するかについて話し合いたいと思っています。 私はコミュニケーションの多くを行い、私が実際に明快さを追加し、混乱を引き起こさないことを確認したいので、これに関するあなたの意見を心から望んでいます。

これは、コミュニティですでに多くの混乱を引き起こしている発表ブログのサンプルに関するものです。

それがブログへの私の貢献であり、ブログがあなたのために混乱を引き起こしたことをお詫びします。 Elmと@aspnetdeのブログへのリンクを追加することで、「これがMVUとは何か」と言っていると

基本的に、著者はまだMVUを実際には調べていないと想定する必要があります。

私たちはこのトピックについて広範な会話と討論を行いました。 想定しないでください、そして私もそうしないようにします。

問題は、それがどのような問題を解決するかということです。

@dersia解決すべき一般的な問題は、開発者に選択肢を与えることです。 MVVMの上にあるMVUが何を解決するかを尋ねているのなら、私にはわかりません。これは、求められていることでも、私たちがやろうとしていることでもありません。

＃28と＃66で提案されているリファクタリングは、データバインディングとMVVM固有のものをレンダラーの実装から分離することであり、MVUを選択した場合、MVVMで使用される追加機能を利用できなくなります。

コードスニペットがどれほどの重みを持つかは予想していませんでした

でもそれが肉ですよね？ そして、それがラベルと一致しなかったのは残念です。

@davidortinau

それがここでのほとんどのコメントの方向性であるように思われます。私たちが何と呼んでラベルを付け、用語をどのように使用するかについて話し合いたいと思っています。 私はコミュニケーションの多くを行い、私が実際に明快さを追加し、混乱を引き起こさないことを確認したいので、これに関するあなたの意見を心から望んでいます。

私の側から何を追加する必要があるのか​​わかりません。 私は自分の立場を大声ではっきりと表現したと思います:-)。 MVUを実装する場合は、開いたドアを押します。 アナウンスの投稿とCometリポジトリのスニペットを見て推測できる場合は、遠慮なくそうしてください。ただし、MVUと呼ぶのはやめてください。

ありがとう。

ドンがこのスレッドで言及されたように：-）-CC： @dsyme

なぜMVUと呼ばれているのかわかりません。 それは素晴らしいパラダイムであり、ここでうまく機能するかもしれません-パラダイムに適合し、混乱しない適切な用語を考えてみませんか？

@aspnetdeあなたの側から何が残ったのですか？ たくさんあると思います:)。
私はあなたの論文のいくつかの部分を読みました。 私はそれが好きだったと言わなければなりません。 ドン・サイムのF＃に関する本も読みました。 関数型プログラミングが好きです。 私の経験からすると、その簡潔さはわかりますが、把握（理解）するのは困難です。 読みやすさは、開発ライフサイクルの非常に重要な部分です。 実際には、コードの読み取りに多くの時間が費やされています。 そして、再帰は書き込みのみです。 一度書くことはできますが、ほとんど誰も読むことができません（正規表現と同様）。
過去に、会社でのプロトタイピング/調査期間中にAngularでReduxを試しました。 エルミッシュの半分のアプローチですか？ 貴重な体験でした。 状態を変更しないように注意する必要があることを学びました。その結果、状態が突然変化する可能性があるスタック全体を覚えておく必要がなくなります。
不変性の利点は理解していますが、テディベアの頭を突然引き裂いたErik Meijerとのプレゼンテーションを見て、現実の世界は可変であることを示しました。

だから私が指摘したいのは、これらのパラダイムに対する私たちの自然な考え方ではないかということです。 あなたの経験は何ですか？

私はXAML / C＃/ MVVMの経験が豊富なので、DonSymeがXAMLを不要と見なしているのはなぜだろうと思います。
私の経験から、関心の分離（UI、プレゼンテーション、ビジネスなどのロジック）に役立ちます。 これらのDSL（C＃マークアップ）とMVUが長期的にコード品質の向上に役立っているかどうかはよくわかりません。 経験のない/思いやりのない開発者は、責任を混ぜ合わせます。 MVUパターンを正しく理解するには、さらに経験が必要ですが、これらのパラダイムの両方を試したので、コミュニティ全体にとって非常に価値があります。
できるだけ共有してください。 ありがとう@aspnetde！

ご理解のほどよろしくお願いいたします。

@davidortinauここで誤解があったかもしれません。私は完全に選択の余地があり、使用するパターン/パラダイムを自分で選択するのはすべての人に任せています。 私はただ、物事に正しく名前を付けるべきだと言おうとしていました。 ソフトウェア開発の誰もが物事に名前を付けることは最も難しいことの1つであることを知っていますが、すでに名前が付けられている明確に定義されたものがある場合は、そうでないものにそれらの名前を再利用し始めるべきではありません。

コミュニケーションの失敗
この場合、間違った言い回しを使用することを修正する必要があると思います。そのためには、このプロジェクトで
a）MVUは私たちがここで話していることの間違った名前であることを理解してください
b）ここで確立しようとしていることを説明する適切な用語を見つける
次にc）全員を更新し、その新しい名前の使用を開始します

まだ戻って修正できる段階にあると思います。 正しくやってみましょう。起こりうる最悪の事態は、XF /マウイコミュニティがMVUを他の世界とは別のものとして理解していることです。

そうは言っても、私はMVUの大ファンであり、MVVMも大好きです。Cometのように流暢なMVVMアプローチ（まだ良い名前はありません）とこれまでに提示されたものは素晴らしく、多くの開発者と私はそれをサポートします、私は名前を修正する必要があると思います。

編集：コミュニケーションを逃してコンテストから脱落した。

不変性の利点は理解していますが、テディベアの頭を突然引き裂くErik Meijerとのプレゼンテーションを見て、現実の世界は可変であることを示しました。

@tomasfabianこれは間違っています。

あなたは世界を一連のイベントとして見始めなければなりません、それはそれが実際に何であるかです（私はここでイベントソーシングの議論を始めたくありません）。
テディベアに起こったことは、新しいイベントがその状態に追加されたということだけです。この場合のイベントは「頭を奪われた」ものです。 そして、一度イベントが発生すると気付くよりも、元に戻すことはできません。また、発生したことを元に戻したり削除したりすることはできません。 頭をテディに戻すには、「体に頭を縫い戻す」という新しいイベントが必要です。 😉

FPとMVUの利点について議論することは、ここではIMHOのトピックから外れています。 この問題は、誤解や正確な命名の可能性についてだと私は思いました。

@isaacabraham多分あなたは正しいです、そして私はそれをお詫びします。 それは私のせいです。 名前を付けることが重要なことは知っていますが、その一方で、問題のタイトルは「MVUはあなたが思っているものではないかもしれません」です。 ですから、名前を付けるよりも少し広いトピックになることを願っています。
ありがとう、トーマス

@tomasfabian MVU、FPなど、現実または想像上の長所と短所について

@davidortinau
どの言語機能とアーキテクチャの変更が役立つかについては、いくつかの提案を提供できることを願っています。

* newキーワードおよびその他の構文上のノイズ。
DartやKotlinとは異なり、C＃は、必須のnewキーワードを永久に使用し続ける可能性があります。これは、オプションにすることは、ファイルごとのオプトインディレクティブとしても、重大な変更であり、人気のない提案であるためです。 したがって、その代わりに、コンストラクターをラップし、少なくともコアセットの初期化のみのプロパティを初期化する静的メソッドを含む公式の（そして維持されている）静的クラス（またはMAUIビュー名前空間ごとの静的クラス）かもしれませんMAUIビューオブジェクト。 次に、ビューコード.csファイルの先頭にusing staticディレクティブを配置し、 newの構文ノイズなしでメソッドを呼び出すことができます。 これにより、C＃ビュー関数の混乱とノイズが少し減少します。 もちろん、これらの静的メソッドコンストラクターラッパーはコミュニティによって自動生成される可能性があります（Xamarin.FormsでCSharpForMarkupで使用するのと同様のことを行いました）が、ボックス内のラッパーのセットをMAUIプロジェクト。

さらに、（MVU / Comet / CSharpForMarkupビュー関数で一般的な）大きな式ツリーの構文の乱雑さやノイズを減らすのに役立つC＃言語の提案は非常に役立ちます。 C＃9は、MVUのM部分とU部分を改善するためにこの点で長い道のりを歩んできましたが、V部分は構文的には依然として問題点です。

*拡張プロパティ*
「extension-everything」の提案が今のところ保留になっていることは知っていますが、MVVM-with-C＃-markup（たとえば、CSharpForMarkup with Xamarin.Forms）に役立つ可能性のあるものの1つは、拡張プロパティです。 CSharpForMarkupでは、すべてのヘルパーを拡張メソッドを使用して実装する必要がありましたが、場合によっては、拡張プロパティ（オブジェクト初期化子で使用可能）の方がはるかに見栄えが良くなります。

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

これは、マークアップにC＃を使用したMVVMのように、可変ビューオブジェクトツリーにのみ実際に適用されます。 MVUまたはその他の機能的なUIアーキテクチャの場合、ビューオブジェクトは不変であるため、これは適用されません。 そのような場合、流暢な拡張方法がさらに適切です。

*状態管理についてあまり意見がない（または必要に応じて低レベル）*
Xamarin.Forms上にMVUを実装する際の最大の障壁の1つは、2つの重要なコンポーネントがないことでした。ビュー関数が返すことができる軽量オブジェクトグラフと、フレームワークが実際のコンポーネントに「レンダリング」できるものです。プラットフォーム固有の表現など）。 そして2番目の部分は、ビュー関数の1つの戻り値と別の戻り値の違いを探すことによって、ヘビーウェイトプラットフォーム固有のビューを効率的に更新する差分エンジンです。これには、部分差分を実行することによって効率的に差分を実行する方法などが含まれます。

MAUIがこれら2つの重要な要素を提供しているようですが、これはすばらしいことです。 ただし、少なくとも表面レベルでは、MVUコミュニティの一部がMVUまたは同様の「機能的な」UIアーキテクチャよりもMVVMに近いと言う、状態を管理するための意見のある方法に非常に密接に関連しているように見えます。 私の好みは、上記の2つの重要な部分（軽量ビューオブジェクトグラフと効率的な差分エンジン）を維持し、開発者によると、MVUまたはCometを効率的に重ねることができる低レベルのコンポーネントシステムと組み合わせるということだと思います。選択。 多分それはすでに目標です、そして私はそれを見ていませんか？ もしそうなら、私は少なくともいくつかの基本的な例でそれについてもっと議論したいと思います。

@aspnetdeなぜ投稿を削除したのですか？

@tomasfabian

私の経験から、[MVVM]は関心の分離（UI、プレゼンテーション、ビジネスなどのロジック）に役立ちます

はい、そうです。 MvvmCrossで構築された大規模なXamarin.iOSおよびXamarin.Androidアプリケーションでいくつかの良い経験をしました。 今日、私はフレームワークよりもライブラリを非常に好みますが、これらのプロジェクトはすべて（6桁のLOCを使用するものもあります）、技術的にもビジネスの観点からも成功していると思います。

アプリケーションのスケーリングに関しては、MVVMは特に優れた仕事をしていると思います。 特に、モノリスの出荷を余儀なくされているモバイルでは、アプリが特定のサイズを通過した後、アプリを独立したモジュールにリファクタリングするのに役立ちました。

これらのパラダイム（[MVU]）に対する私たちの自然な考え方ではありませんか？ あなたの経験は何ですか？

そうは思いません。 ストレージ用のReduxの経験を生かして、アプリケーション全体がその利点の恩恵を受けることを想像してください。 一見するともっと複雑に見えますが、私の経験では、理解して操作する方がはるかに簡単です。 @forkiがよく指摘するように、単方向のデータフローによって常に何が起こっているのかが明確になるため、ほとんど退屈です。

これらのDSL（C＃マークアップ）とMVUが長期的にコード品質の向上に役立っているかどうかはよくわかりません。

MVUとMVVMの両方に異なる利点がありますが、両方に異なる欠点もあります。

私たちのMVVMプロジェクトが成功していることを考慮したにもかかわらず、私のチームと私はそれらをデバッグすることで髪の毛を失いました。 特にあるプロジェクトでは、すでに指摘したように、新しいチームメンバーの経験不足や誤解によって引き起こされた複雑さに悩まされ始めました。 厳密に適用した場合、MVUではそれが起こりにくいと思います。なぜなら、それは物事が非常に狭く機能する方法の境界を定義し、それから抜け出し、間違った方法で物事を構築することは、他の方法よりもほとんど難しいからです。

MVUの場合、2つの大きな問題があります。 最初：スケーリング。 多くの人が単一のプログラムを提唱しています。 私はここで懐疑的です（そして複数のプログラム/モジュールがより良い方法だと思います）。 2番目：現在、FabulousのようなものがXamarin.Formsの上にあります。 つまり、iOS / Androidの上の抽象化レイヤーの上にある抽象化レイヤーの上にある抽象化レイヤーです。 それは非常に複雑です。 したがって、誰も気にしない未解決のバグに対処するだけでなく、一方の抽象化レイヤー（Fabulous）をもう一方（Xamarin.Forms）が変更されたときに更新することも、多かれ少なかれ退屈で不快な作業です。

それがMAUIにとって大きなチャンスだと思います。 私は正直に言って、すばらしいメンテナがここでマイクロソフトと力を合わせてくれるのを見たいと思っています。 そして、組織の他の部分が過去に行ったように、マイクロソフトがそれを台無しにしないことを本当に望んでいます。

トーマス

先日、公式発表を読んでいたとき、そこに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 ++)
    )
};

私に関する限り、これはMVUではありません。 なぜそう思うのかについて、私はすでにいくつかの考えをここに書き留め

私が理解しているように、Xamarin.Forms上にMVUを実装し、後にFabulousになるものを構築するために、2018年の数か月を費やしたDon Symeは、もう少し外交的ですが、収益は同じです。

それで、私のポイントは何ですか？

• C＃でもF＃でも、実際のアーキテクチャパターンを実装してください。 ファビュラスの背後にいる人々に手を差し伸べることは、ここからのスタートかもしれません。
• あなたがそれに興味がないが、 Cometライブラリとして今日利用可能なものの上に構築することについて明確なビジョンを持っているなら、その「アプリモデル」にもっと適切な名前を使うことを検討してください。 何か新しいものを発明する。 MSMVUという名前を付けます。 なんでもいい。 ただし、オレンジ用のリンゴは販売しないでください。

乾杯！

なぜ彼らはそれをMSMVUと名付けるのでしょうか？ 彗星はMVUであり、今後もそうなります。 そしてマウイはMVUです。

.NETMAUIがMVUであるかどうかを言うのは時期尚早だと思います

MAUIが最終的にMVUになるかどうかではありません。 これは、コミュニティですでに多くの混乱を引き起こしている発表ブログのサンプルに関するものです。 基本的に、著者はまだMVUを実際には調べていないと想定する必要があります。 「C＃MVU」について話しても、これは改善されません。

混乱を招くことはありません。 C＃がMVUを実行しているのを見て、一部の人々はそれを処理できないというだけです。

明確なガイドラインがない場合でも、SwiftUI（Cometがそのインスピレーションの大部分を取得する）は、そのパターンをMVVMと呼ぶ傾向があります。
しかし、MVUについての言及は見つかりませんでした。

@TimLariviere https://github.com/Clancey/Comet#key -concepts
基本的にCometはそれをMVUと呼んでおり、MVUの古い定義にあるメッセージループのポイントがすでに欠落しています。

明確なガイドラインがない場合でも、SwiftUI（Cometがそのインスピレーションの大部分を取得する）は、そのパターンをMVVMと呼ぶ傾向があります。

この投稿の冒頭にある例を見ると、間違いではありません： https ：

しかし、MVUについての言及は見つかりませんでした。

同じ投稿で、それについても簡単に説明しています（SwiftUI + Redux = TEAの組み合わせとして）。 その後、「クリーンアーキテクチャ」に奇妙な方向に進んでいますが😄

私はここで言及されたので、私はいくつかのことを言うだけです。

• MAUIは素晴らしいと思います。アーキテクチャとしてのMVUについて学ぶことは、人々がMAUIを理解するのに役立つと思います。

• 言葉に夢中になるのは簡単です。使用する言葉を調整する時間は十分にあり、正確な用語についてのメッセージは聞いた。 個人的には、Elmは、「MVU」の装飾されていない、修飾されていない使用は、明示的なメッセージ、明示的な更新、機能モデル、機能ビューの再計算、および差分更新を意味することを確立したと思います。 しかし、MVUには多くの

• 人々はこの分野で非常に強い信念や意見を持っている傾向があり、非常に個人的に物事をとることができることに気づきました。 私はそれがどのようなものかを知っています、そしてプログラミング言語のデザインのように、私は空間のすべてのポイントに賛否両論があると思います。 最高のテクノロジーを実現するために、皆さんが試して、使用し、学び、共有し、協力することをお勧めします。

@dsyme
Comet / MAUIアーキテクチャの適切な用語は、単方向データフロー（またはUDF）のバリエーションであると思いますが、MVU自体はUDFの非常に特殊なバリエーションであるため、MVUではありません。 MAUI / Cometは確かにUDFフレームワークとしての資格がありますが（SwiftUIと同様）、MVUフレームワークとしての資格はありません。 UDFには、MVU、Flux、Redux、Reactなど、いくつかのバリエーションがありますが、MVUがまったくないときにCometMVUを呼び出すのは誤解です。

MVUとは異なり、モデルは変更可能であり、表示機能のコードによって変更されます。 次に、ミューテーションが観察され、ビューは再レンダリングによってそれらのミューテーションに反応します。 ビューが変更されていないため、それでも単方向ですが、更新機能、メッセージ、およびメッセージディスパッチはありません。したがって、MVUではありません。 これは、MVVMの一方向のバリエーションに近いものです。

@JeroMiyaありがとうございます、その用語のリファレンスはありますか？

@dsyme具体的な参考資料はありませんが、Reactの初期の頃、特にReact自体と、ReduxやFluxなどの初期のパターンのいくつかに関連して使用されている用語を最初に聞き始めました。 いくつかのUDFバリアント（主にReactスペース）について説明した記事を覚えていますが、今は見つかりません。

とはいえ、これは正式なアーキテクチャではありません。ビューがイベントに応じて変化するステートフルオブジェクトツリーであるのとは対照的に、ビューがモデルの関数であるという基本的な概念に似ています。 UDFの概念は、モデルがどのように更新されるか、またはモデルが可変か不変かを必ずしも指定するわけではありません。 MVUは、UDFの概念をビュー自体だけでなく、モデルの更新プロセスにも拡張します。 したがって、MVUではモデルも不変であり、UI状態の変更は、新しいモデルを生成するコマンドとして表され、新しいビューをトリガーします。

もちろん、これは新しい概念ではありません。Reactの前でさえ、Asp.Net MVC、Rails、PHPなどのほとんどのサーバー側Webフレームワークは技術的に単方向としてカウントされます。 Reactが登場する前は、主流のSPAフレームワークとクライアント側のUIフレームワークでは一般的ではありませんでした。

@dsyme具体的な参考資料はありませんが、Reactの初期の頃、特にReact自体と、ReduxやFluxなどの初期のパターンのいくつかに関連して使用されている用語を最初に聞き始めました。 いくつかのUDFバリアント（主にReactスペース）について説明した記事を覚えていますが、今は見つかりません。

とはいえ、これは正式なアーキテクチャではありません。ビューがイベントに応じて変化するステートフルオブジェクトツリーであるのとは対照的に、ビューがモデルの関数であるという基本的な概念に似ています。 UDFの概念は、モデルがどのように更新されるか、またはモデルが可変か不変かを必ずしも指定するわけではありません。 MVUは、UDFの概念をビュー自体だけでなく、モデルの更新プロセスにも拡張します。 したがって、MVUではモデルも不変であり、UI状態の変更は、新しいモデルを生成するコマンドとして表され、新しいビューをトリガーします。

もちろん、これは新しい概念ではありません。Reactの前でさえ、Asp.Net MVC、Rails、PHPなどのほとんどのサーバー側Webフレームワークは技術的に単方向としてカウントされます。 Reactが登場する前は、主流のSPAフレームワークとクライアント側のUIフレームワークでは一般的ではありませんでした。

@JeroMiyaこれに感謝します、これはまさに私がMVUを理解する方法です。
MVUを最良の形式で使用および例証する最も古く、現在も主に使用されているアプリケーションの1つは、MSExcelです。

@dsymeがあなたのコメントを読んでいる私はあなたが議論されたアーキテクチャ（MVVMを備えたCSharpForMarkup）の用語としてMAUIを参照しているように感じます。
これはあなたがマウイであると理解していることではないこと、またはそうであるかどうかを私に明確にしてください。
私の理解では、MAUIは将来XFに取って代わる次のMSアプリケーションフレームワークにすぎません。

私はこの問題のやり方が本当に好きで、コメントが進んでいます。 参加してくださった皆様、ありがとうございました。 たぶん一緒に、適切に確立され、名前が付けられたMAUIの可能なフレーバーとしてすべての異なるアーキテクチャを取得できます。

@dersiaありがとうございます！ CSharpForMarkupでの私自身の経験からのメモ：これはMVVMよりも少し低いレベルです-C＃マークアップをより合理化して見栄えよくするための一連の拡張メソッドとユーティリティのセットです。 ViewModelバインディングを簡単にするヘルパーがあるので、MVVMパターンを確実に実装できますが、最終的には、ViewModelではなくReduxですべてのビューロジックを実装することになりました。 ビュープロパティを状態セレクターにバインドするためのいくつかの拡張メソッドを追加する必要があります。これは、Redux状態ストアのSelectおよびDistinctUntilChanged演算子に渡すFunc<StateType, ChildStateType>です。 Observable<StateType> 。 完全に一方向のデータフローではありませんが、FabulousのようにUIオブジェクトツリーの差分と表示機能を実行する成熟した方法がありませんでした。

少し前に、REST警察は、私たち全員がRESTと呼ばれるべきではないことを私たちの喉に押し付けようとしました。 今日でも誰もがそれをRESTと呼んでおり、私たちは皆まだ元気です。 😉

@bitbonk RESTコミュニティは、ますます多くのものがミックスに投入されるにつれて、それがますます役に立たなくなったため、この用語をあきらめました。 彼らは現在、「ハイパーメディア」を使用して、代表的な国家移転を指しています。 今日のRESTは、実際には「SOAPではない」または「JSONover HTTP」を意味するだけであり、どちらもそのコアアイデアの伝達に成功していません。 ここのコメント投稿者は、MVUの同じ運命を回避することを望んでいます。

@davidortinau @ tomasfabian 、MAUIでのMVUの例はまだ見ていません。 今夜は例を考えてみます。 ここで、WinFormsに対して同様のことを行い

@JeroMiyaありがとうございます、その用語のリファレンスはありますか？

@ dsyme 、React Fluxに端を発していると思いますが、ゲームアーキテクチャ、つまりDoom3を@TIHanと

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

これがC＃の例での私の試みです。 実際の例としてこれを試すために利用できるMAUIがありません。 プレビューはありませんよね？ とにかく、これはアイデアの大まかな翻訳です。

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

ビュー部分を除いて、私はかつて似たようなことを簡単に

私はMVUに比較的慣れていないので、多くの人と比べて、MVUを使用した経験はほとんどありません。 しかし、MVUのコンセプトは間違いなく私の興味を引き、楽しんでいます。 C＃開発者にMVUパターンでの開発を支援するフレームワークが提供されているのを見てとてもうれしく思います。

MAUI MVUは典型的なMVUではなく、SwiftUIから大きな影響を受けていることに完全に同意します。 その主な著者であるClanceyhimeslefは、彼のほとんどすべてのセッションでそれを非常に明確にしています。 ReduxはMVUの影響を強く受けていることは誰もが知っています。SwiftUI、Flutter、その他の多くのフレームワークも同様です。 それらのどれも純粋なMVUではありません。

しかし、私たちは皆、これらすべてのフレームワークに最も近いアーキテクチャパターンがMVUであることに同意します。 それが人々がそれを参照する理由です。 また、フレームワークのブログタイトルについて話していることを思い出してください。このフレームワークは、もう1年半後にリリースされる予定です。

そして、あなたが人々がこのブログのタイトルに腹を立てていると言うなら。 本当に心配する必要はないと思います。 コミュニティはまだ継続する必要があります。 このフレームワークをより良くするために私たちのエネルギーを費やしましょう。 細部についてはあまり気にしないでください。

しかし、私たちは皆、これらすべてのフレームワークに最も近いアーキテクチャパターンがMVUであることに同意します。 それが人々がそれを参照する理由です。

犬、馬、猫、チンパンジーはすべて互いに非常に接近しています。 これからは、それらすべてを猫と呼びます。

:)まああなたはする必要はありません。 しかし、私に何かを話させてください：猫、トラ、ヒョウなどは猫と呼ばれています。 そして、私はあなたがそれを持ってきてくれてうれしいです。 Cozはまさにここに当てはまります。

@aspnetde ：トーマス、そうは言っても。 あなたのオリジナルのMVUブログは、コンセプトを非常に明確かつ正確に説明している最高の記事の1つであると言わざるを得ません。 私はそれからかなりのことを学びました。 ありがとう

@ libin85まさに問題があります。 あなたは実際に1つのカテゴリーにあるものを列挙し始め、そうでないものを無視しました。 MAUIサンプルをMVUカテゴリに入れると、基本的にチンパンジーを猫カテゴリに入れます。

不変のビューのように、MVU実装との類似点があります。 ただし、メッセージループや明示的な更新機能がないなど、明らかな違いがあります。 モデルはビューで直接変更されます。 これは、MVUを思いついたときに人々が明らかに望んでいないことです。 一部の言語では、それを行うことさえ不可能です-それがMVUが登場した理由です。 そして、なぜそれが人気になったのか。 ここで、MVUの定義からこれらのプロパティを削除する場合は注意が必要です。

@forki ：私はあなたが言ったことに反対していません。 実際、ブログ投稿のタイトルではなく、コミュニティとして議論する必要があるのは、最後のコメントで指摘した点です。 それが私のポイントです。 それは議論する前向きなことであり、フレームワークはそれから利益を得るでしょう。

私は、名前がより重要な側面から気を散らしてはならない少し詳細であることに同意します。 しかし、私がそれを提起した理由は、私が個人的にMAUIを、常識が最終的に一般的に合意された解決策につながるコミュニティの取り組みとは見なしていないためです。 これは、最終決定が密室で行われているマイクロソフト製品です。 私は私の懸念を提起するために顧客としてここにいます。

しかし、私たちは皆、これらすべてのフレームワークに最も近いアーキテクチャパターンがMVUであることに同意します。

@ libin85これが最も近いアーキテクチャパターンであることに同意し

私は、名前がより重要な側面から気を散らしてはならない少し詳細であることに同意します。

いいえ、名前は重要です。 それらは、その意味を確立することも保持することも困難です。 上で説明したRESTも参照してください。 RESTは悪用されているため、マーケティング用語として以外は意味がありません。 特にMAUIの「MVU」が提供するものに既存の用語がある場合は、MVUにそれが起こらないようにしたいと思います。

価値があるのは、MAUI「MVU」がMVVMオプションの優れた代替手段だと思います。 RESTの場合と同じように、何かを便利で良いものにするために定義的なことをする必要はありません。 明確に定義され確立されたパターンから明らかに逸脱する代替案で名前を混乱させないでください。 結局のところ、MVUはMVVMおよびCometオプションの優れた代替手段になるでしょう。

価値があるのは、MAUI「MVU」がMVVMオプションの優れた代替手段だと思います。 RESTの場合と同じように、何かを便利で良いものにするために定義的なことをする必要はありません。定義から明らかに逸脱している代替案で名前を混乱させないでください。

フルACK。

なぜ彼らはそれをMSMVUと名付けるのでしょうか？ 彗星はMVUであり、今後もそうなります。 そしてマウイはMVUです。

@ saint4evaそれらはMVUとして「販売」されていますが、定義上はそうではありません。

私は、名前がより重要な側面から気を散らしてはならない少し詳細であることに同意します。

いいえ、名前は重要です。 それらは、その意味を確立することも保持することも困難です。 上で説明したRESTも参照してください。 RESTは悪用されているため、マーケティング用語として以外は意味がありません。 特にMAUIの「MVU」が提供するものに既存の用語がある場合は、MVUにそれが起こらないようにしたいと思います。

価値があるのは、MAUI「MVU」がMVVMオプションの優れた代替手段だと思います。 RESTの場合と同じように、何かを便利で良いものにするために定義的なことをする必要はありません。 明確に定義され確立されたパターンから明らかに逸脱する代替案で名前を混乱させないでください。 結局のところ、MVUはMVVMおよびCometオプションの優れた代替手段になるでしょう。

私はあなたが言ったことのほとんどに同意しますが、「マウイMVU」はまだ悪くて混乱していると思います。 私はおそらく「マウイMVP」またはMVCで行くでしょう。 どちらも機能し、MVUよりもブログ投稿に表示されるものに近いです。

編集追加：
提案されたバージョンがどこにあるのかさえわかりません。 つまり、MVVMのロジックはViewModelに存在し、MVUの場合は更新関数内に存在し、MVPの場合はプレゼンターに存在し、MVCの場合はコントローラーに存在します。

すべてが住んでいるビューがありますか？ それとも、ビュー、ロジック、モデルを提供するドメインモデルによって名前が付けられたクラスにすべて存在しますか？ モデルは別個のクラス（タイプ）またはレコードであると想定されていますか？

これが私にとってここでの大きな問題点だと思います。それがどのように「提示」されるのか見当がつかないため、更新、モデル、および表示機能があることがわかりません。

箱から出して、MAUIはこれまでに説明したパターンよりも少し低いレベルであるように見えます。実際には、これらの他のパタ​​ーンのモデル（または状態）とビュー部分だけです。 これらの他のパタ​​ーンを実装するためにおそらく構築できるもの（状態管理は少し意見が分かれていますが）。

したがって、たとえば、 State<T>のTがViewModelのようなクラスであり、データモデルクラスの個別のセットを追加すると、最終的にはMVVMのようなものになります。一方向ビュー。

一方、Reduxのような状態管理システムを追加し、Redux状態モデルをState<T> Tとしてプラグインすると、最終的にはMVUに非常に近いものになります。 、Elm / Fabulousのような従来のMVUほど完全には統合されていませんが。 FabulousがXamarin.Formsで行うように、MAUIビューをMVUフレームワークの背後に隠すことができるかもしれません。

MAUIを介してMVCまたはMVPパターンを実装する方法がわかりません。 大まかな最初のパスとして、「アクション」をビュー関数に公開する別のクラスを作成したかどうかを考えています。 たとえば、MAUI確認ダイアログがあり、「controller」クラスに「ClickOK」メソッドと「ClickCancel」メソッドがあるとします。 MAUIビューは、クリックイベントをビューからコントローラーに転送します。コントローラーは、新しいモデルを生成するか、既存のモデルを変更します。

@JeroMiya同意します。間違いなく、Reduxパターンを使用すると、MVUに近づけることができ、アーキテクチャの運用を大幅に減らすことができます。 私はReact-Redux、React-Hooks、ReactiveXの幸せなユーザーであり、最近はBlazor Apps：heart： Fluxor ：heart：を使用しています。 @mrpmorrisがこの会話に貢献するかもしれません。

これがC＃の例での私の試みです。 実際の例としてこれを試すために利用できるMAUIがありません。 プレビューはありませんよね？ とにかく、これはアイデアの大まかな翻訳です。

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

これにより、Microsoftのサンプルよりも、更新のパフォーマンスコストが高くなりますか？ このモデルでは、私が理解している場合、MSサンプルではなく、すべてのUI要素を含む新しいビューがインスタンス化され、既存のビュー要素はそのままにして、ラベルの値を更新するだけです（ -これが持つ可能性のあるサイジングコスト）。

この違いは、ネーミングに関するこの議論を推進する主要な違いの1つであるように思われるため、従来定義されているMVUアーキテクチャに、UIを効率的に更新するための他の技術があるかどうか、もしそうなら、それらはレンダリングエンジン？

パフォーマンスに関する@markmccaigue ：多くの場合、MVUシステムには仮想ビュー（またはhtmlの場合は仮想DOM）と差分エンジンが付属しています。 したがって、仮想DOMとDOMを区別した後、フレームワークはDOMにパッチを適用するだけで済みます。 これは通常、特に不変のデータ構造で作業する場合に非常に効率的です。

こんにちは！！

とりあえずこの問題を閉じます。これについて話し合いたいのですが、githubはそれを機能させたくありません：-/

誰かがこの会話を続けたい場合は、ディスカッションアイテムを作成してから、この問題を参照してください