2009-03-02 7 views
2

私は現在、私が働いている会社のすべての開発者にSilverlight(v2)について教える予定です。唯一の問題は、自分自身で実際のSilverlight体験がないことです。もちろん、データバインディングやレイアウトなどの技術に関するすべての詳細を学んだので、私は同僚を助けることができます。しかし、情報を見つけることが難しいことの1つは、一般的なプロジェクトの構造です。おすすめのプリズムv2 Silverlight/WPFプロジェクトの構造

私はP & Pプリズム2のパスをたどることにしました(多分後でミックスの中でいくつかのWPFを投げる)とあなたのいずれかの巧妙な人々がプリズムを使用して実際のプロジェクトを開発した経験を持っている場合ので、私は思っていました2、またはWPFだけでなく、プロジェクト/ソリューションの構造についてご意見がありましたら教えてください。 「どこに意見を書いていますか?または "モジュールプロジェクト命名規則はありますか?"

ご協力いただければ幸いです。

答えて

7

これは、私の経験では、Silverlightではなく、WPF用のPrismを使用しています。私はプリズムの専門家ではなく、これらのいくつかで簡単に私の心を変えることができます。 :-)

  • すべてのモジュールを作るのは魅力的です。しないでください。あなたの構築時間はすぐに吹き飛ばされ、あなたは非常に分断された解決策を残しています。代わりに私は静的にロードされた1つのメインモジュールを持っていて、ベースパッケージに必要なものがすべて含まれています。アドオンやエクストラは、動的にロードされる他のモジュールになります。 1つのモジュールを少し破るだけの価値があるかもしれませんが、その数は小さくしておいてください。これは読み込み時間にも役立ちます。

  • このアイデアが良いかどうかはわかりませんが、ViewとViewModelのインターフェイスをView/ViewModel自体と同じファイルに保存したいと思います。私はMVVMパターンがたくさんのファイルを生成する可能性があり、ファイル数を減らすので、これが好きです。欠点は、Intefaceとその実装が分離するのが難しいことですが、私はこれを行う必要はないでしょう。このテクニックはテストを妨げることはありませんが、これはもう一つの利点です。

  • ビューはViewsフォルダに入り、各ビューのフォルダになりがちです。各ビューのフォルダには、View、ViewModel、Presenter(必要な場合)が含まれています。

  • リファレンス実装では、モジュール間で共有する必要のあるすべての共通クラスのインフラストラクチャプロジェクトを作成します。参照実装には詳細がありますが、これは共通サービスインタフェース、定数などのあらゆる種類のものに使用できます。

関連する問題