私はMVVMとSilverlightでビデオを読んだり見たりしています。私は、Silverlightにはかなり慣れていませんが、.NETには慣れていません。 MVVMであることを知らずに、WPFアプリでMVVMを使用したのは興味深いことです。データとXAMLの間のレイヤーとして機能する、簡単にバインドできるクラスを作成していました:)
私たちが開始するプロジェクトは、Silverlight5とバックエンドのWCFを使用して行われます。
プロジェクトはかなり大きく、それぞれに50個のモジュールまたは画面がいくつかあります。理想的にはそれらをオンデマンドでロードしたいと思います。ほとんどの(すべてではない)UIは、単純なデータ入力のものになります。
私は、私たちのアーキテクチャがどうあるべきか、そしてそれが将来どのように私たちに利益をもたらすかを見極めようとしています。
MVVMとその理由については、私はそれを手に入れたと思います。 Caliburn Microもチェックしました(そしてそれが何をするのかを理解しました)。 ReactiveUIとMVVMLightが表示されます。正直なところ、私は外部のライブラリ/依存関係が好きではありません。また、命名規則を使用して外部フレームワークを満足させることはあまり気にせず、XAMLでのバインドは完全に問題ありません。 SL5には優れたコマンドサポートとXAMLデバッグがあるので、外部フレームワークは必要ないと思います。
したがって、ViewModelを使用し、コードビハインドでビュー関連のコードを最小限に抑えてXAMLを介してバインドすることは、私にとってはまったく問題ないと思います。
これが私のジレンマです:
ありがとう!
私は約1年前にクライアント用のMVVM(WPF)アプリケーションを作成しました。アプリは複数のモジュールで構成され、画面ごとに最大t050フィールドの数十の画面があります。画面/領域管理のMVVMフレームワークにPrismを使用しました。多言語サポートを処理するための別の単純なフレームワークを追加し、自分でセキュリティを構築しました。
Prismがすべての画面領域のものを処理することは有益であることがわかりました。それは私が心配する必要がなかった仕事の塊でした、そして私は問題に対処するときに作業サンプルとオンラインヘルプを得ることができました。一部のエリアでは、ガイダンスが欠落しているか、ライトが点灯していました(ポップアップ画面とフィールドセキュリティ)私は自分の道を進みました。 Prismは、モジュールの検出機能と画面処理機能をすべて処理しました。 Silverlightには、ネットワークの遅延など、さまざまな懸念事項があります。これらの懸念は、既存のフレームワークを使用すれば対処できたはずです。
一部のモジュールにはWebサービスバックエンドがあるため、手動でコーディングされたVMおよびモデル。1つにはEntity Frameworkバックエンドがあるため、VMは手作業でコーディングされ、モデルが生成されました。RIAバックエンドを簡単に見てみると、5分間のデモに適しているように見えましたが、多くのビジネスロジックを備えた複雑なアプリケーションにどれだけ対応できるかはわかりません。
長くも短くも、完全なMVVMパスをたどる場合は、MVVMフレームワークを使用することをお勧めしますが、必要なすべてをカバーしていない可能性があることに注意してください。アプリケーションが本当に単純な場合、RIAへの直接バインディングは機能しますが、コミットする前に最も複雑な画面に対して検証します。これは、セキュリティと検証、および単純なものをチェックすることを意味します。