自分のプロジェクトでMVPを使用する方法
当局は、同じTodoプロジェクトを実装するために異なる概念とツールを使用して、いくつかのMVPサンプルプロジェクトを作成しました。
- todo-mvp / -mvpインフラストラクチャの例。
- todo-mvp-loaders /-mvpインフラストラクチャプロジェクトに基づいて、データ取得部分はローダーアーキテクチャを使用します。
- todo- databinding /-データバインディングコンポーネントを使用して、mvpインフラストラクチャプロジェクトに基づいています。
- todo-mvp-clean /-クリーンアーキテクチャの概念を使用して、mvpインフラストラクチャプロジェクトに基づいています。
- todo-mvp-dagger / -mvpインフラストラクチャプロジェクトに基づいて、依存関係の注入にdagger2が使用されます。
- todo-mvp-contentproviders / -todo-mvp-loadersアーキテクチャプロジェクトに基づき、コンテンツプロバイダーを使用
- todo-mvp-rxjava / -mvpインフラストラクチャプロジェクトに基づくフルネームでは、同時実行性とデータレイヤー処理にRxJavaを使用します。
この一連のMVPオープンソースユースケースの正式リリースの前に、MVPモデルの使用方法を教える優れたオープンソースプロジェクトもインターネット上に多数あります。これまで読んだことがない場合は、実際には別の利点があります。公式に従ってください私が始めるとすぐに、他の同様のプロジェクトが失敗した。以前に実装したものよりも少しシンプルで明確な公式のtodo-mvpを確認しました。また、テストケースもより完全に記述されているため、この点でMVPの利点を直感的に体験できます。
MVPの利点と問題
MVPモデルを理解すると、その利点は明白です。
- UIレイヤーはロジックレイヤーから分離されており、UIレイヤーにはビジネスロジックコードが含まれていないため、特定のレイヤーへの変更でコードをどこでも変更する必要はありません。
- テストは非常に便利です。Presenterレイヤーを直接呼び出してテストスタイルを作成できます（Junitフレームワークを使用できます）。
- 最後は保守性とスケーラビリティです。MVPの各カテゴリの責任は非常に明確で単一であり、その後の拡張と保守が容易になります。
もちろん、欠点も明らかです。まず、コードクラスが増加します。小さな関数のPresenterレイヤーとModelレイヤーの実装を記述する必要がある場合があります。以前は、これらを一度にViewレイヤーに追加しました。同時に、新しいプロジェクトの担当者が既存のモードを破壊するコードを書かないようにするために、MVPモードのトレーニングが必要です。