つまり、MVC が選択肢にない場合でも、MVP は次善の選択肢でしょうか?
私のように、グリーン フィールド プロジェクトに参加する余裕がなく、Web フォーム UI をリファクタリングしてプレゼンテーションをビジネス オブジェクトからより適切に分離したいと考えている人がいると確信しているので、ここで質問したいと思います。 .
私は、比較的小さな要件、機能強化、およびバグ修正を追加するタスクを負ったレガシー アプリケーションに取り組んでいます。
ここで取り上げるアプリケーションの部分は、リレーショナル データベースに永続化されるビジネス オブジェクトに対する一連の CRUD 操作の UI として特徴付けられる場合があります。
既存の UI は、MultiView コントロールを使用して、関連付けられたビジネス オブジェクト (1 対 1 の関連付けまたは 1 対多 / 親子) の編集間を移動します。はい、そうです - すべてが 1 ページにあります。残念ながら、UserControls の使用は非常に控えめであるため、マークアップとコード ビハインドは数百行の長さになります。
各ビューで、FormView はさまざまな ObjectDataSources を介してビジネス オブジェクトの CRUD を管理します。各 FormView の ItemTemplate 内で、さまざまなサーバー コントロールが ObjectDataSource のフィールドまたはメソッドにデータバインドします。
関心の分離をさらに導入し、ページのコード ビハインドから大量のコードを取り出したいと思います。
これまでの私の調査では、次のことを検討できることが示唆されています。
Model View Presenter のフレーバーを使用します。より具体的には、Web Client Software Factory の ObjectContainerDataSource を使用して、現在の UI と一連の新しい Presenter クラスの間のブリッジを容易にします。
MVC フレームワーク (オプションではありません) を使用してゼロから再構築します。
よく放っておきます。MVP パターンは、異なる UI シナリオでプレゼンテーションを再利用する必要がある場合にのみ正当化されますか?
(3) で解決したとしても、プレゼンテーションをより適切に分離するためにリファクタリングを開始する方法を知りたいと思います。
あなたならどうしますか？感謝して受け取った他のアイデア...
興味のある人のための背景を次に示します。
ドメインは製薬研究にありますが、それはかなり無関係であり、非常に典型的な基幹業務 (アプリケーションの別の部分の動作条件を形成する一連の設定のユーザー構成) と考えることができます。
ビジネス オブジェクト層は、非常に一貫した方法で既に構築されています。気に入らないかもしれませんが、必ずしも変更を正当化することはできません。各オブジェクトは、「ID による取得」および「条件によるリストの取得」のための静的メソッドがあるという点で、独自のリポジトリ/データ アクセス オブジェクトです。可能な場合、一般的な操作は抽象基本クラスで実装されます。各ビジネス オブジェクトは、ADO.NET 2.0 プロバイダー ファクトリ メカニズムを使用して具体的なプロバイダーから比較的抽象化された状態を維持するデータ アクセス層にデータ アクセス作業を委任します。この点で、Microsoft Enterprise Library の Data Access Application Block を使用するすべてのアプリと多くの共通点があります。
NUnit で記述されたかなり徹底的な統合テストがあり、テスト データベースをゼロからセットアップするため、実行に時間がかかりますが、少なくとも、それらが正常に機能することを確認します (とにかく過去のある時点で ;-)。真の単体テストは (まだ) ほとんど行われていません。