基幹業務アプリケーションにおける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が残っていないことに気付いたときのように、少し恐竜のように感じました。私が気に入らなくても、前進することが唯一の選択肢です。

私の見解は、イベントとコードビハインドを伴う「昔ながらの方法」であるWinformsでの長年の経験からです。したがって、最も単純なアプリケーションを超えると、コードはすぐに大きな泥の塊になることは間違いありません。それは、当時のアプリケーションの記述方法であるため、避けられませんでした。

Webformsもまったく同じですが、ステートレスシステム（Web）よりもステートフルな抽象化であるという複雑さが追加されます。Rob Coneryが言ったように：

WebFormsは嘘です。それは、偽りに包まれた抽象化であり、流し込みと巧みな技でいっぱいのプレートに提示された嘘のタレで覆われています。Webformsで行うことは、Webとは何の関係もありません。Webに任せてください。

これは、dynamicC＃のキーワードとわずか400行のコードを使用して、完全に機能するオブジェクトリレーショナルマッパーを作成した人によるものです。彼が何かについて権威をもって話すとき、私は聞きます。

私が現在取り組んでいるアプリケーションは、メインフォームにいくつかのタブがあるWinformsアプリケーションです。フォームを各タブに動的にロードできます。私はMVVMやMVPには従いませんでしたが（このようなライブラリでは可能です）、フォームの実行に絶対に必要なコードだけを残して、できる限りのコードを個別のアセンブリに積極的にプッシュしました。まだ数百行のコードがあり、フォームのコントロール定義、プロパティ、イベントハンドラーの割り当てを含む部分的なクラスは数えていませんが、フォームに何か新しいものを追加する必要がない限り、もう一度触れる必要はありません。

フォームとKey / Valueペアのコレクションを渡すことができる静的メソッドがあり、（Reflectionを使用して）キーをフォームのフィールドに自動的に照合し、コレクションの値をフォームに入力します。フォームのフィールドからキーと値のペアのコレクションを取得して、その逆を行うこともできます。全体で約20行のコードですが、フォーム上の40のコントロールに対して40のカスタム割り当てステートメントを記述する必要がないため、使用するたびに採算が取れます。

そのキー/値リストを取得してXMLにシリアル化し、ファイルに永続化することができます。従来のDTOを渡すことができる他のフォームがあり、そのフィールドをフォームにマップします。これは、Winformsの「泥の大きなボール」スタイルでは実用的ではありません。適切なデカップリングが利用されている場合、それはほとんど取るに足らないことです。

これは聞き覚えがありますか？そうすべき; それは本質的に貧乏人の形のデータバインディングです。

確かに、私はWPFのデータバインディングが本当に好きです。これを利用するために、データコンテキストをウィンドウ自体に設定します。ウィンドウは、ビジネスクラスやその他の監視可能なプロパティにアクセスできます。

よかったね。MVVMに準拠している必要はありません。ただし、MVVMのようなパターンは、開発者が大きなシステムを構築するのを支援するために作成されたことを覚えておいてください。 ダイアログを表示するだけの場合は、そのすべての配管が必要なわけではありません。

WPFのようなシステムの複雑さの一部は、一般的な方法で特定の問題を解決しようとするすべてのプログラマーライブラリに固有です。 そのためには、プログラマーがライブラリーを使用する可能性があるすべての実用的な方法を考慮する必要があります。これは複雑さを増しますが、ライブラリを適切に設計する人にとっては、統一された一貫した方法で物事を行うという哲学を表にもたらします。

John ResigのjQueryライブラリを考えてみてください。これはまとまりのある設計の本質であり、DOMに関する多くの奇妙な詳細、およびブラウザーによるDOMの処理方法のバリエーションを隠しています。JavaScriptを数行書くだけの方が簡単ですか？時々。しかし、一貫性のある統一されたAPIでjQueryコードを作成することの利点は、次に来る人があなたの行動を理解し、必要に応じてそのコードを維持することを容易にします。

「大きなアプリケーション」モデルでの実際の経験は、ASP.NET MVCの使用です。 WinformsがWPFに対応しているのと同様に、ASP.NETはASP.NET MVCに対応しています。 私がASP.NETで働いていたとき、私はいつも自分の意思でそれを曲げるのに苦労しました。ASP.NET MVCはあなたに曲がります。使うのは楽しいです。明確で体系的なシステム構造を生成し、アプリケーションとマークアップを完全に制御できます。JavaScript、jQuery、CSSを自由に使用でき、ASP.NET MVCが邪魔になりません。

私の唯一のハードルはそれに慣れること、そしてそれを自分の言葉で知ることでした。

さらに読むには
Rob ConeryがMVCを学ぶ必要があります