MVP パターンでアプリケーションを設計および開発しました。これを実現するためにソフトウェア ファクトリを使用したことはありません。次に、SCSF パターンと CAB 構造に移行します。
CAB 構造は MVP のみを実装しているため、より簡単な方法で実行できるかどうかを知る必要があります。
2 に答える
1
私はワリに同意します。ビューの準備ができました。彼らが完璧なMVPにいると仮定します。次に、それらをモジュールに分類する必要があります。子ワークアイテムを作成したため、ユースケースが開始されると、モジュールのワークアイテムコレクションに追加された子ワークアイテムの新しいインスタンスになりました。したがって、ユースケースが完了すると、子ワークアイテムを終了するだけです。例外が発生した場合、childworkitemは、モジュールの作業項目で影響を受けるものです。SCSFには、画面上に複数のビューを作成できる機能があります。したがって、ZoneWorkspaceを使用してUIとロジックの重複を回避できるかどうかを確認する必要があります。モジュールがどのように通信するか、たとえばイベントやコマンドを決定します。ビューとモジュール間でデータがどのように渡されるか。これでシェルができました。シェルに配置するすべてのリージョンを決定する必要があります。シェルにデフォルトで付属しているもの。モジュールがシェルをリッスンする方法。Shellがモジュールからリッスンして自身をカスタマイズするイベント。
SCSFには依存性注入があります。したがって、使用するUIサービスを決定します。それに応じてプレゼンターにそれらを注入します。
于 2011-08-17T20:48:52.533 に答える
0
CAB と SCSF には、コード対応の MVP クラス (およびインターフェイス) があります。したがって、それをきれいに実装した場合は、クラスのコツをつかんだら、メソッドをコピーするだけで済みます。
簡単に説明しようとします:-
1) IView -- ビューのリファレンスであり、プレゼンター (または他のクラス) がアクセスできる設定されたプロパティ/メソッドのみを公開します。
2) ビュー -- プレゼンターの参照を持ち、プレゼンターのすべての公開/保護されたメソッドにアクセスできます。設計上、WorkItem (サービス、状態、コマンド、イベントなどのコンテナー) が必要になるため、どのサービスにもアクセスできません。すべての実用的な目的で、ビューは UI コントロール、バインディング、オブジェクトの状態などを管理するためだけに存在します。
3) プレゼンター -- WorkItem への参照があります (これを介してすべてのサービスにアクセスできます)。サービスを利用してデータを操作することは、プレゼンターの責任です。
4) WorkItemController -- WorkItemController は、UI コントロールの配線/配線解除、ビューの配置など、ユースケース関連の機能を使用できます。
UI アプリケーションの全体的な設計として、SCSF/CAB の単なる MVP ではありません。次のものがあります：-
- モジュール構造
- オンデマンド アーキテクチャ。
- サービスパターン
- コマンド
- イベントハンドラなど
そのため、最初にcodeplex ドキュメントをチェックして、プロジェクトがそのプラットフォーム/アーキテクチャで簡単にアップグレードできるかどうかを確認する必要があります。始めたばかりで、プロジェクトをスケーラブルでエンタープライズ レベルにすることを考えている場合は、CAB/SCSF をお勧めします。
于 2011-05-30T07:06:19.463 に答える