android - Android の MVP モデルとは何ですか?通常のイベント処理関数の作成との違いは何ですか?

Question

Android の MVP モデルとは何ですか?通常のイベント処理関数の作成との違いは何ですか?

MVP には、Android ビュー オブジェクトを保持し、データを処理し、ビューを更新するための追加のプレゼンター クラスがありますか?

通常のイベント処理関数の作成との違いは、イベント処理関数内のコードがプレゼンター クラスに移動されることです。

しかし、これだけの違いであれば、特別なことではないようです。私たちはコードを書くときに非常に抽象的ではありませんか?ビジネス ロジックを一緒に抽象化するのに、なぜ MVP の概念を分離する必要があるのでしょうか?

Answer 1

個人的な利点は次のとおりです:
1. ロジックが明確で、インターフェイスは View に属し、データ処理は Presenter に属するため、Activity と Fragment の爆発が発生しません。コードを削除すると、その後のメンテナンスやアップグレードも困難になります。他の人が書いたコードを見ると、階層が明確でなく、非常に難しいと最も懸念されます。
2. テストが便利です。テストのために View にバインドする必要がなく、エラーのトラブルシューティングが簡単です。

Answer 2

おっしゃるとおり、ビューの処理には Presenter を使用してください。
私の意見による利点: 1. プレゼンターは通常、ビューのインターフェイスを受け取ります。この DIP (依存性反転原理) の適用により、実装されている限り任意のビューを使用できるようになります。これらのインターフェイスは処理ロジックを共有します。
2. SRP (単一責任原則) の適用により、データ処理ロジック層をビューから分離および切り離すことができます

実際には、OCP の原則によれば、アクティビティには v1 v2 v3 のバージョンが含まれる可能性があるため、開発は少しランダムになります。以前のコードを再度プッシュしたり、以前のコードに基づいてコードを変更したりすることは危険で非効率な動作です。MVP を使用している場合、v2 または v3 バージョンを使用している場合、いくつかのコントロールが追加されている可能性があります。この時点で前のコードを直接変更する場合、MVP フレームワークは役に立ちませんが、拡張された方法で開発する場合は、さらにいくつかのコントロールが必要になります。元のビューのインターフェイスを継承し、新しいプレゼンターを作成して古いビューを継承し、そこに新しいロジックを記述します。これは、メンテナンスとテストに便利です。新しいコードとその安定性をテストするだけで済みます。プログラムはセックスを強化することができます。

つまり、MVP モデルに従って書くと、コードの保守性は知らず知らずのうちに強化されます。