1

MVP で単純なログイン ケースをどのように実装できるのだろうか。私の MVP フレームワークでは、ビューからのみイベントを発生させることができます。プレゼンターからイベントを発生させることはできません。これが良いことか悪いことかはわかりません。それには利点がありますが、単純なケースは追加の間接化で爆破されます.

したがって、単純なログイン シナリオを実装する場合は、次のようになります。

  • ログインプレゼンター
  • ログインビュー
  • ログインモデル

では、ユーザーがログイン フォームに入力してログイン ボタンをクリックするとどうなるでしょうか。

  1. ビューは「ログインがクリックされました」というイベントを発生させます
  2. プレゼンターはそのイベントをリッスンし、そのモデルを使用してログインを行います
  3. ログインが成功した場合は、ビューを再度呼び出して、ログインが成功したことを通知する必要があります。
  4. ビューは別のイベント「ログイン成功」を発生させます。
  5. プレゼンターと他のプレゼンターは別のビューを表示し、ログイン ウィンドウを閉じます。

私の観点からすると、イベントを成功させるためのビュー経由のステップは多すぎます...

フレームワークが間違っていて、プレゼンターからイベントを発生させないのでしょうか、それともこれは MVP の必然的な悪ですか?

4

1 に答える 1

1

各フレームワークは、ビューがプレゼンターをトリガーする方法、またはその逆の正確な方法に関する独自のルールを定義します。他のフレームワークが少し簡単に見えるかどうかを調べる必要があります。ただし、全体的な取り組みは同じままになる可能性があります。

ログインのような単純なプロセスでは大変な作業のように思えるかもしれませんが、私の意見では、単体テストの容易さの利点を考えると、苦労するだけの価値があります。

ビューとモデルをモックすることで、ログイン プロセスをテストできます。プレゼンターは無効な入力を正しく処理しますか? ログインが間違っている/正しい場合、ビューは正しいプロンプトを表示しますか? これらの質問はすべて、モデルとビューのモック オブジェクトを使用した単体テストで回答できるようになりました。

ビューとモデルがインターフェイスとして定義されていることを確認してください。単体テストに役立つJMockなどのライブラリを確認してください。

次に、顧客の注文を処理するなど、より複雑なシナリオでこのフレームワークがどれほど役立つか想像してみてください。

于 2012-08-02T10:57:07.243 に答える