Silverlight で開発するために、50 以上のテーブルを含む 200 以上のページなどの非常に大規模なプロジェクトのフレームワークを検討してきました。このような大規模なアプリケーションを開発するためのベスト プラクティスやフレームワークの提案はありますか? うまくいけば、最終的なアプリケーションを構成するのは複数のテクノロジーであり、これに関するあなたの意見を知りたいと思っています. 私の友人の 1 人が、最高のフレームワークの 1 つとして Caliburn を指摘してくれました。そのような大規模なアプリケーションを開発するためにそれを使用した人はいますか?
2 に答える
2
私たちはすべてのプロジェクトで Caliburn を使用しています (ただし、Caliburn を開発したのは私たちなので誤解を招く可能性があります)。:-)
Caliburn はデータ アクセスとは関係がないため、テーブルの数は影響しません。「ページ」の数も影響を与える必要はありません。「ページ」という用語を使用すると、ナビゲーション (ブラウザー スタイル) UI の比喩を念頭に置いていると思われます。その場合、そのアプローチを使用する場合でも Calbiurn の恩恵を受けることができますが、それは自然な「Caliburn の方法」ではありません。
要約すると、アプリケーションのサイズと複雑さは問題ではありません。Caliburn が役立つ理由をよりよく理解するには、ここから始まるRob Eisenberg による一連の投稿を読むことをお勧めします。
オリジナルの Caliburn の代わりに、Caliburn Micro を使用する新しいプロジェクトを奨励していることに注意してください。役立つ追加のリソースは、MIX 10 の Rob のビデオである可能性があります。Robは、独自のフレームワークを (Caliburn とは別に) ロールする方法について説明しています。
于 2010-10-11T18:15:55.190 に答える
1
カリバーン上に構築されたわずかに小さいプロジェクト (約 30 ページ) があります。私が見ているように、追加のページで唯一複雑になるのはメモリ消費です。これは、追加設定なしの動作の caliburn がすべてのページ (画面/ビューモデル) を初期化し、それらをメモリに保持するためです。これを処理する独自の方法を作成しました。これは、そのページが要求されたときにのみビューモデルを作成する一種の「レイジー スクリーン コンダクター」であり、それを閉じる方法もあります (したがって、ガベージ コレクターに破棄させます)。したがって、アプリケーションに 30 ページまたは 300 ページがあるかどうかは問題ではありません。開いているページに必要なだけのメモリを消費します (ユーザーが 300 ページすべてを一度に開く必要はないと仮定します)。
ところで: Caliburn.Micro に移行する予定なので、このフレームワークに移行する必要があります。一方、Caliburn.Micro ははるかにクリーンです (また、以前の Caiburn のソリューションを作成したときよりもはるかによく理解しています) ので、ソリューションをリファクタリングすることをお勧めします。
于 2010-10-19T18:55:59.467 に答える