0

私は WinForms アプリケーションを継承しましたが、これにはビジネス ロジックと UI コントロールの間の懸念事項の分離に関する重大な問題があります。この 2 つは完全に絡み合っているため、重大なリグレッションを発生させずに UI の変更/拡張を行うことはほぼ不可能になっています。

MVP リファクタリングの提案の一環として私が直面している問題の 1 つは、モデルに影響を与えるアクションを定義する最善の方法です。アプリケーションの複数の領域で使用されるこれらのアクション (顧客履歴の更新など) が多数あるため、モデルの対話をプレゼンターに直接コーディングしたくありません。

特定の永続オブジェクトに影響を与える多くのアクションは、(静的メソッドではありますが) そのオブジェクト内に既にカプセル化されています。このパターンを続けて、リファクタリングしてメソッドをインスタンスベースにするか、メソッドを別の API のようなクラスのセットに分割する必要がありますか?

編集：

ここで私が本当に求めているのは、モデルを定義するクラス内でモデルに影響を与えるメソッドをカプセル化してもよいですか、それともこれらの POCO を保持し、API をモデルに定義する別のクラス セットにメソッドを実装する必要があるかということです。

4

1 に答える 1

0

MVP アーキテクチャを使用している場合、ビジネス ロジックと UI が絡み合ってはなりません。ビジネス ロジックと UI の間にプレゼンターが座っているためです。Presenter は View のインターフェイスのみを認識し、Presenter は View のイベントをサブスクライブします。知られていることはそれだけです。ビューのコントロールを自由に変更できます-配置、置換、色の変更-UIのもの。これらの変更は Presenter には影響しません。もちろん、これらの変更はビジネス ロジックには影響しません。

次にプレゼンターについて。UI イベントを Model の呼び出しに変換し、IView インターフェイスを介して UI を更新するだけです。モデルへの呼び出しはどういう意味ですか? 場合によります。ビジネスロジックが存在するWCFのようなサービスへの呼び出しである可能性があります。これは、アプリケーションまたはドメイン サービス オブジェクト、またはリポジトリへの呼び出しである可能性があります (ドメイン駆動設計に関して)。しかし、ビジネス ロジックがあってはなりません。プレゼンターは、UI イベントからモデル呼び出しへの単純なトランスレーターです。いくつかの DTO オブジェクトを作成して View に割り当てることはできますが、実際の業務はありません。

そしてモデル。モデルは、Presenter によって呼び出されるすべてのクラスです。ここにビジネス ロジックがあります。また、ビジネス ロジックは複製されません。顧客履歴を更新する必要がある場合は、CustomerRepository か、SalesService などのサービス オブジェクトになります。そして、そのオブジェクトはすべてのプレゼンターによって呼び出され、顧客履歴を更新する必要があります。

アドバイス - ビジネス オペレーションに静的メソッドを使用しないでください。オブジェクトを密結合します。標準のテスト フレームワークではテストが不可能になります。インスタンス メソッドを使用します。インターフェイスを実装します。それらを嘲笑します。システムが疎結合になり、テスト可能になります。MVPパターンの利点が見えるところです。

于 2013-03-17T07:33:53.027 に答える