個人的には、Mobile Software Factory は CF にとってあまり楽しいものではないと思います。私たちはまだその一部 (EventBroker) を使用しており、可能であればその部分を削除したいと考えています (一般的なイベントをサポートしておらず、引数を EventArgs から強い型にキャストする必要があるため)。仕事中の姉妹プロジェクトは、UI の一部にそれを使用していましたが、パフォーマンスの問題のために取り除かなければなりませんでした (別の大きなプロジェクトですが、それ自体にもパフォーマンスの問題があります)。
P&P lib が提供する MVP フレームワークで私が見つけた問題は、フォームを所有するプレゼンター/コントローラーではなく、フォームとコントロールがプレゼンターを所有していることです (「それは単なるビューです」を読んでいない人: Pragmatic Programmer?)。これは、MS の "フォーム ファースト" 迅速なアプリケーション開発のマントラに見事に適合しますが、CE でウィンドウ ハンドルがどれほど高価になる可能性があるかを考えると (多数のウィンドウがある場合)、残念です。非常に大規模な CF アプリケーションを実行しており、独自の MVC フレームワークを展開しています。独自のものを展開するのは難しくありません。すべてをコントローラー、ビュー、ビジネス オブジェクト、およびサービスに分離し、コントローラー間の相互作用を制御する UIController を用意してください。
実際にはさらに一歩進んで、Controller->View->Layout パターンを使用してフォーム/コントロールを再利用します。コントローラーは通常と同じで、ビューはレイアウトを特定のビューにカスタマイズするオブジェクトであり、レイアウトは実際の UserControl です。次に、これらを 1 つの Form で入れ替えます。これにより、使用する Windows コントロールの量が大幅に削減されます。この + 起動時にすべてのフォームを初期化するということは、新しい Windows コントロールを「オンデマンド」で作成するときに発生する顕著な一時停止をなくすことを意味します。
明らかに、大規模なアプリケーションを展開している場合にのみ、この種のことを実行するだけで十分です。およそ 20 種類以上のビューがあり、合計で約 7 種類のレイアウトを使用しています。これは初期化ルーチン (起動時にフォームをロードするため) に約 10 秒の損害を与えますが、心理的にはほとんどのユーザーは、実行時の顕著な一時停止とは対照的に、起動時のこのようなヒットを喜んで受け入れます。
私の本での P&P ライブラリの主な問題は、それが FF -> CF ポートであり、2 つのプラットフォーム間の特定の非互換性とパフォーマンスの違いにより、多くの便利な機能が失われることです。
ところで、これは私が今まで読んだ MVC/MVP に関する最も包括的な記事です。Windows アプリケーション (デスクトップまたは CE) の場合、Taligent Model-View-Presenter バージョンを対話、コマンド、および選択なしで使用することをお勧めします (たとえば、コントローラー/プレゼンターがすべての作業を実行します)。