MVC デザイン パターンの説明を読みましたが、いくつか質問があります。私は Android 開発者 (ジュニア) で、コードをより明確にしたいと考えています。それで、MVCを使用する必要がありますか?また、すべてのアクティビティには独自のモデルが必要ですか? それのための良いチュートリアルはありますか?ありがとうございました。
3 に答える
すでに実装されています。Android の MVC パターン
Android は事前に構築された MVC であるため、何もする必要はありません。
MVC は、物事を行う特定の方法 (アクティビティとモデルの 1 対 1 の関係など) というよりも、一種のアイデアです。アイデアは、モデル、ビュー、およびコントローラーを分離して、意味をなすようにすることです。
Android では、複数のアクティビティが 1 つのモデルを参照できます (たとえば、検索可能な家のリストを含むアクティビティ、「家の編集」アクティビティ、それらを座標のポイントとして示すマップ)。2 番目の質問に答えると、いいえ、彼らは独自のモデルを持つ必要はありません。
はい、それが理にかなっている場合は、MVC を使用する必要があります。モデルは実際のアプリケーションとは別のエンティティであり、アクティビティはモデルの「ユーザー」であると考えてください。
Android では、MVP (モデル、ビュー、プレゼンター) パターンが全体的なシステム アーキテクチャとより直接的な相関関係にあることがわかりました。アクティビティはビューで構成され、MVP セットアップでは、独自のイベントを管理し、独自の外観を制御します。プレゼンターは、モデルとビューの間のファシリテーターとして機能し、ビューが要求したときにデータを提供します。必要に応じて、プレゼンターはサービスである場合とそうでない場合があります。ビュー/モデルの比率に関しては、ある時点で画面に表示しようとしているものに大きく依存します。Android が携帯電話でのみ実行されていたときは、アクティビティとモデルの間にほぼ 1 対 1 の相関関係があることが理にかなっていました。さて、通常のケースでは、モデルとフラグメントの間に 1 対 1 の相関関係があります。
ただし、MVC を実行したい場合は、フラグメントがツールボックスのツールになっているため、特によく開発されたイベント システム (RoboGuice に含まれているものなど) を使用すると、以前よりもはるかに簡単になります。フラグメントを次のように考えてください。ビュー、およびコントローラーとしてのアクティビティ - ビューの順序付け、モデルからのデータの提供、および他のコントローラーへの遷移の処理。
どのパターンを選択するかは、ニーズによって異なります。アプリケーションがサービス主導型である場合は、MVP の方が適しているでしょう。ただし、アプリがデータベース上の単なるシン クライアントである場合は、MVC の方が簡単かもしれません。それはすべてあなた次第です :)
MVP の「開始」リソース: http://www.jamespeckham.com/blog/10-11-21/MVP_on_Android.aspx