Android の MVP モデルとは何ですか?通常のイベント処理関數(shù)の作成との違いは何ですか?
MVP には、Android ビュー オブジェクトを保持し、データを処理し、ビューを更新するための追加のプレゼンター クラスがありますか?
通常のイベント処理関數(shù)の作成との違いは、イベント処理関數(shù)內(nèi)のコードがプレゼンター クラスに移動(dòng)されることです。
しかし、これだけの違いであれば、特別なことではないようです。私たちはコードを書(shū)くときに非常に抽象的ではありませんか?ビジネス ロジックを一緒に抽象化するのに、なぜ MVP の概念を分離する必要があるのでしょうか?
擁有18年軟件開(kāi)發(fā)和IT教學(xué)經(jīng)驗(yàn)。曾任多家上市公司技術(shù)總監(jiān)、架構(gòu)師、項(xiàng)目經(jīng)理、高級(jí)軟件工程師等職務(wù)。 網(wǎng)絡(luò)人氣名人講師,...
個(gè)人的な利點(diǎn)は次のとおりです:
1. ロジックが明確で、インターフェイスは View に屬し、データ処理は Presenter に屬するため、Activity と Fragment の爆発が発生しません。コードを削除すると、その後のメンテナンスやアップグレードも困難になります。他の人が書(shū)いたコードを見(jiàn)ると、階層が明確でなく、非常に難しいと最も懸念されます。
2. テストが便利です。テストのために View にバインドする必要がなく、エラーのトラブルシューティングが簡(jiǎn)単です。
おっしゃるとおり、ビューの処理には Presenter を使用してください。
私の意見(jiàn)による利點(diǎn): 1. プレゼンターは通常、ビューのインターフェイスを受け取ります。この DIP (依存性反転原理) の適用により、実裝されている限り任意のビューを使用できるようになります。これらのインターフェイスは処理ロジックを共有します。
2. SRP (単一責(zé)任原則) の適用により、データ処理ロジック層をビューから分離および切り離すことができます
つまり、MVP モデルに従って書(shū)くと、コードの保守性は知らず知らずのうちに強(qiáng)化されます。