なぜユーザー/手書きコードが最小限で、XAMLですべてを行うのですか？

MVVMコミュニティは、90年代のOOプログラマーのように熱心になったように感じます。MVVMはコードのない同義語です。私の閉じたStackOverflow質問から：

多くの場合、コードビハインドではなくXAMLで同等のことをしようとしている人についての投稿に出くわします。彼らの唯一の理由は、コードを「クリーン」に保つことです。私が間違っている場合は修正しますが、そうではありません：

XAMLも-BAMLにコンパイルされます-その後、実行時にコードを解析する必要があります。XAMLは、コンパイル時にコンパイラによって検出されないため、より多くの実行時バグを潜在的に持つ可能性があります-誤ったスペルから、これらのバグもデバッグが困難です。すでにコードビハインドがあります-似ているか、InitializeComponent（）; 実行する必要があり、その中の.gicsファイルには多くのコードが含まれていますが、非表示になっている場合があります。純粋に心理的ですか？ウェブのバックグラウンドから来て、コードではなくマークアップが好きなのは開発者だと思います。

編集：私はXAMLの代わりにコードビハインドを提案しません-両方を使用します-私はXAMLでもバインディングを行うことを好みます-私はWPFアプリでespの背後にコードを書くことを避けるためにあらゆる努力をすることに反対です-それはの融合でなければなりません両方を最大限に活用します。

更新：マイクロソフトのアイデアでさえありません。MSDNのすべての例は、両方でそれを行う方法を示しています。

XAMLにすべてを追加することを提案する人はいません。

実際、それはひどい考えだと思います、IMO。

問題は、歴史的に、それがあったので、背後にある自分のコード内のロジックは、そこに属していなかったたアプリのWinformsから来たロジック。そこでVMの重要性が生まれます。これにより、ビューをモデルに結び付ける部分を分離できます。

したがって、ビューは、最適なもの、つまりUIのみを処理するために残されます。

さて、もしあなたのUIがコードを必要とするような状況に陥ったら、どうしてもそれを利用してコードビハインドに入れてください。ただし、そこにあるシナリオの95％では、マークアップファイルにUIを残しておく方が良いでしょう。また、何らかのコードが必要な場合は、おそらくいくつかのロジックを書き出そうとしています。より適切にビューモデルに委ねられます。これに対する例外は、ビヘイビアーなどですが、それらは完全に別個の動物であり、特別な場所が必要です（つまり、コードビハインドではありません）。

質問に直接答えて、すべてのインスタンスでコードビハインド（ビジュアルコントロールクラスにあるコード）を具体的に参照していると「コード」と言うとき、その理由は、ユーザーインターフェイスを完全に実装できるためです。 1つのテクノロジーのみを使用してBlendで操作します。前提は、UXデザイナーは開発者ではなく、コードでの作業を望まず、コーディングの専門家ではなくレイアウトとXAMLの専門家であるということです。コードビハインドなしですべてを実装する場合、これらの種類のデザイナーに、言語で完全に動作するために必要なツールを提供できます。

命令型プログラミングと宣言型デザインを明確に分離します。

これは、SilverlightおよびWPFに「動作」が存在する原動力です。コードビハインドにコードを追加する代わりに、ビヘイビアを独自の小さな再利用可能なモジュールにします。その場合、Blendを使用すると、文字通りコントロールにドラッグアンドドロップできるという利点があります。これで、XAMLコントロールに1回限りの可動部分を持たせる代わりに、可動部分をデザイナーツールを使用して操作できる素敵なコンテナーに抽象化しました。

私の経験では、これは多くの場合、XAMLトリガーで複雑なロジックを使用してコードビハインドから遠ざけようとすることになります。 -モデル。

xamlでできることをすべて行うことの最大の利点の1つは、すべての動作を1か所に保持できることです。開発者がxamlとコードの間をジャンプしなければならないたびに、xamlを理解するのが難しくなります。

コードビハインドの削減を優先事項としないWPFチームに参加しました。いくつかのイベントハンドラーがコントロールを操作していて、動作が2つのファイルに散らばっているのですぐには分からなかったため、デバッグがはるかに難しいことが何度かありました。

そうは言っても、デザインの原則に妥協する方がよい場合があると考えるのは正しいと思います。xamlで行うのは非常に難しいことがあります。コードビハインドを使用することで、はるかに短い時間で実行できた動作をxamlで動作させるために、何時間または何日も費やしました。コードビハインドを最後の手段として扱うようになりましたが、コードビハインドを使用してはならないことを誰かに伝えることはありません。優れたエンジニアが理解する必要があるもう1つのトレードオフです。

編集：コメントから、私の投稿はxamlに対して議論していると解釈されているようです。私の意図は反対を主張することでした。純粋なxamlは、すべての動作を1か所に保持するため、常に推奨されます。xamlと分離コードの組み合わせは複雑になる可能性があるため、分離コードを最小限に抑えることが理想的です。多くの理由で、Xamlは純粋なコードビハインドよりも望ましいです。WPFとSilverlightは、xamlで記述されるように設計されています。

私はXAMLの非常に表面的な知識しか持っていませんが、コンパイラがタイプミスを検出しないのは困惑させます。

基本的な違いは、XAMLは宣言型であり、たとえばC＃は必須であるということです。

簡単に言えば：

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

対

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

上のコードは実際に副作用によって階層を作成しますが、下のコードは単純にそれを宣言します。また、たとえばaddChildメソッドの名前が変更される可能性がありますが、child-parent-relationshipはセマンティックモデルの中心であり、宣言スニペットでそのように表されることにも注意してください。実装からはほど遠いため、遅延インスタンシエーションなど、その下での完全な透過的な最適化が可能です。
宣言型プログラミングには多くの利点があります。より簡潔で表現力豊かで、モデルに非常に近いです。私はそれが望ましい限り行きます。

ただし、これは、すべてをXAMLにパンチする必要があることを意味するものではありません。C＃には、宣言スタイルを可能にする多くの高レベルの構造があります。

最終的に、コードは短く、読みやすくする必要があります。したがって、XAMLよりも少ないコードでC＃で同じことを達成できる場合、C＃を使用するのは論理的です。ただし、XAMLコードは、使用されるコンポーネントの変更に対する脆弱性がはるかに少ないという意味で、より「ポータブル」であり、.NETフレームワークを抽象化します（たとえば、バインディングの実装方法の詳細）。