SilverlightプロジェクトでModel-View-ViewModel（MVVM）パターンを使用する必要がありますか？
Silverlightコントロールの課題の1つは、プロパティがコードにバインドされると、Blendで実際に編集できなくなることです。たとえば、データフィードから入力されたListViewがある場合、Blendでコントロールを編集するときに要素は表示されません。
WPF開発コミュニティによって作成されたMVVMパターンは、Silverlightコントロールを「ブレンド可能」に保つのにも役立つと聞いています。私はまだ頭を包んでいますが、ここにいくつかの説明があります：
- http://www.nikhilk.net/Silverlight-ViewModel-Pattern.aspx
- http://mark-dot-net.blogspot.com/2008/11/model-view-view-model-mvvm-in.html
- http://www.ryankeeter.com/silverlight/silverlight-mvvm-pt-1-hello-world-style/
- http://jonas.follesoe.no/YouCardRevisitedImplementingTheViewModelPattern.aspx
潜在的な欠点の1つは、パターンに追加のクラスが必要になることですが、必ずしもコードが増えるとは限りません（上記の2番目のリンクで示されています）。考え？
SilverlightアプリケーションにはMVVMパターンを使用する必要があると思います。このパターンの利点の1つは、いくつかの簡単な手法でアプリケーションを実際にブレンド可能にすることができることです。私はよく「ブレンド性」を「デザイン性のためのデザイン」と呼びます。つまり、特定の手法を使用して、アプリケーションがブレンドで見栄えがすることを確認します。
Torbjørnが指摘しているように、テクニックの1つは、依存性注入フレームワークを使用し、コードがBlendで実行されているか、ブラウザーで実行されているかに応じて、外部サービスのさまざまな実装を提供することです。そのため、Blendでコードを実行するときにダミーのデータプロバイダーを使用するようにコンテナーを構成します。これにより、リストボックスやデータグリッドなどの設計時のサポートが得られます。
多くの場合、課題はDataContextを宣言的に設定する方法です。そのため、IoCコンテナの「フロントエンド」としてサービスロケータークラスを使用することになります。そうすれば、データコンテキストをサービスロケーターのプロパティにバインドできます。
もう1つの手法は、Design TimeDataContextとRunTimeData Contextの2つのプロパティを持つある種のObjectDataSourceコントロール（非ビジュアル）を作成することです。コントロールは、実行されている場所を検出し、ParentDataContextを適切なオブジェクトに設定する役割を果たします。
あなたの質問に答えられるかどうかはわかりませんが、以下の記事は非常に貴重なものです。 JonasFollesø は、デザイン/ブレンドモードのときにninjectを使用してサービスを切り替えています。非常に素晴らしい！
http://jonas.follesoe.no/YouCardRevisitedImplementingDependencyInjectionInSilverlight.aspx
私もJonasに同意します Silverlightを使用したMVVMに関して。 MVPも良い選択だと思いますが、最近、SilverlightでMVPとMVVMの両方を試す時間があり、MVVMの結果に非常に満足しています。 （はい、MVVMを使用するほど気が変わりました）。 VMは、MVVMのビューからモデルのバインディングを（明らかに）抽象化し、MVPよりも多くのバインディングシナリオ（少なくともよりクリーンな方法）を可能にします。ただし、これは1つの側面にすぎません。 。
私のサイトにSilverlightを使用したMVPとMVVMの両方の例をいくつか投稿します。
ViewModelパターンが大好きで、強くお勧めします。ブログに「ViewModelの使用を開始する」タイプの投稿がいくつかあります。
私はいくつかのオプションを試しましたが、私にとって最良の選択としてMVVMを選択しています。ブレンド可能性は重要なポイントであり、動的な動作や手続き型の効果やアニメーション（NikhilのSilverlight.FXなど）をリギングするためのVMアスペクトは直感的です）。ある時点で、ブレンドを完全に回避しようとしました。流暢なインターフェイスを介して、しかし長期的にはUIと動作の結合が非常に苦痛だと感じています。BlendでUIを設計してから、コードにエフェクトやその他の動作を追加したいので、これが私にとって最良のパターンであることが証明されています。これまでのところ。
私たちの多くは、先駆者たちが先に進み、SilverlightのMVVM（さらに言えばWPF）を使用して本当に優れたサンプルアプリを作成するのを待っていると思います。 SilverlightでのICommandの欠如 、または アニメーションとの対話 データバインディングのみを使用した開始と停止の難しさなど、いくつかの注意が必要な領域があります。
それは間違いなく将来を見据えたパターンであり、それを完全に理解できない場所で時々「不正行為」を気にしないのであれば、試してみる価値があります。
私はジョナスに同意します 。 MVVMは私にとって最適なモデルのようです（John PapaはMVPの方が理にかなっていると考えていますが）。 3月に発表されるこれに関するMSDNの記事があり、良い例を求める声に応えてくれることを願っています。
ところで、MVVMフレームワーク部門にある程度の結束が見られることを望んでいます。フレームワークが従うべき良い解決策はまだありません。 Jonas '（Jonas'はFXフレームワークだと思います）が好きですが、WPFと互換性がないため、一部のユーザーにとっては適切な選択ではない可能性があります。
MVVMパターンの非常に優れたTechdays2010ビデオ紹介があり、明確に説明されています。
高度な自動テストを必要とするより複雑なアプリケーションの場合、それは間違いなく理にかなっています。また、DependencyPropertiesからDataContextバインディングへの移行は、ASP.NETの対応するものよりもはるかに優れています。
Silverlightで私が見つけた最大の課題は、実際のUI（これまでのところ1つの商用フレームワークがあると思います）と、SilverlightでWCFサービス（またはWebClient）を使用するときに発生するイベント呼び出しの膨大な絡み合いをテストすることです。
実際のプロジェクトでのMVVMとSilverlightに関する私の記事を見て、自分で決めてください。
http://alexburtsev.wordpress.com/2011/03/05/mvvm-pattern-in-silverlight-and-wpf/
P＆PによるPrism v2の2009年2月のリリースにより、SilverlightとWPFでMVVMのサポートがさらに向上しました。詳細については、 Microsoft.com/compositewpf を参照してください。
私はいつもMVVMとPresntationModel http://martinfowler.com/eaaDev/PresentationModel.html は本質的に同じものだと思っていました。 PresentationModelは言うのがずっと簡単です。 Javaスイング、Windowsフォーム、WPF、Silverlightでうまく使用しました。関心の分離の観点から考えると、プレゼンテーションモデルは非常に理にかなっています。1つのクラスだけがあります。懸念は、プレゼンテーションに適したモデルを提供することです。画面に表示するためにどのテクノロジを使用するかは実際には関係ありません。実装の詳細が変わる可能性がありますが、情報をどのように表示するかに関係なく、懸念を分割することをお勧めします。その分離により、ビューテクノロジに関係なく、プレゼンテーションモデルに対してテストを簡単に作成できます。これはプラスです。