基幹業務アプリケーションにおけるMVVMの価値（および現在の開発手法の現状）
2年経った今でも、実用的なソフトウェアを作成する実用的な方法としてMVVMに取り組んでいます。素晴らしい場合もあります。私は、MVVMの概念がなければナイトメアであった小さな組み立てラインを制御するマルチスレッドアプリケーションを実行しました。物理的な組み立てラインからの抽象化は、ほとんど簡単なことではありませんでした。 ただし、私のキャリアのほとんどは、ビジネスアプリケーションの内部ラインを中心に展開します-ビジネスの運用を形式化および最適化します。このようなアプリには、一般にCRUDと複合操作を中心に展開するビジネスティアーがあります。LOBでは、私のビューモデルはビジネスクラスメソッドの1行のラッパー関数の非常に単純なコレクションになり、最終的にはメッセージボックスの表示やウィンドウのオープンなどの最も単純なタスクが複雑になるだけです。何十年も前から存在しているWindow.ShowDialogの呼び出しについて、「依存性注入」と「メッセージングプロバイダー」の長い説明を読むと、奇妙に感じる人はいますか？winformsで非常に単純なタスクのアドバイスを求めるスタックオーバーフローに関する他の質問はいくつありますか？ 誤解しないでください-MVVMがあり、シュリンクラップされて販売されているソフトウェアパッケージの水平開発を行っている大規模なチームにとって、これは非常に貴重です。ビューモデルのユニットテストでは、RTMのバグを回避することで数百万ドルを節約でき、専用のUI開発者が豊かなエクスペリエンスを提供できます。しかし、再導入のコストが最小限で、ビジネスで支払うすべてがシンプルなソフトウェアである場合、ビジネスロジックがすでにユニットテストされているのに、なぜ単純な「ラッパー」VMのユニットテストに時間を費やす必要があるのでしょうか。キュートなアニメーションと配色にビジネスが費やす時間はどれくらいですか？後輩開発者がやるべきことはありますか（以前は「Save_Click」を見ていた保存機能のバグを追跡し、 確かに、私はWPFのデータバインディングが本当に好きです。これを利用するために、データコンテキストをウィンドウ自体に設定します。ウィンドウは、ビジネスクラスやその他の監視可能なプロパティにアクセスできます。そうすることで、ほぼすべてのMVVMの「ルール」を破ります。しかし、少なくとも、読みやすいシンプルなイベントドリブンコードがあり、新しいデータバインディングと検証を利用できます。問題はデザイナーにあります-私はあまり使いませんが、2012年に統合されるようになったことを願っています-デザイナーは、ウィンドウとその基本クラスが持つ数百のプロパティを表示します。 関連性のある人のために、リソース、本、またはこれを飲み込みやすくする視点の変更にさえ私を向けることができます。MVVMをもう一度試してみますが、前回、依存関係の注入について心配していて、VMからのメッセージボックスを表示するだけでかなり愚かだったので、単体テストの意図はありませんでした。単体テストを行ったとしても、恐ろしい「密結合」アプリケーションのコンパイル時エラーとランタイムテストを交換することで、本当に品質が向上しますか？ 1つの答えは、winformsにとどまることです。しかし、WebFormsの最後のサポーターの1人として（私はWeb開発の傾向について同じ批評を多く持っています）、Microsoft認定トラックにWebFormsが残っていないことに気付いたときのように、少し恐竜のように感じました。私が気に入らなくても、前進することが唯一の選択肢です。