Androidのアーキテクチャについて考えてみる

Androidアプリのアーキテクチャ(MVPとかMVVM)について,いろいろな資料を見ながら自分なりに構成してみる試みです.

参考資料

構成は次の資料を元にしてアレンジを加えたものになります.

モジュール構成

全体の大まかな構成についてです.

  • View: UIを提供するモジュール.
    • Activity: Fragmentを1個以上DIする.Fragmentの表示制御を行う.Activity自体はUIを提供しない.
    • Fragment: 対応するViewModelを1個だけDIする.UIの実体を提供する.DataBindingしてViewModelが保持している情報を表示したり,ユーザー・OSからのイベントを受け取ってViewModelに投げたりする.
  • ViewModel: Fragmentと1対1で対応.Repositoryを1個以上DIする.Repositoryからの情報を受け取ってViewに合うように変換したり,Fragmentから投げられたイベントを処理したりする.処理が肥大化する場合はUseCaseに任せる.
  • UseCase: Repositoryを1個以上DIする.ビジネスロジックを担当するクラス.
  • Model: ビジネスロジック,データ保持など.
    • Repository: Entityと1対1で対応.対応するDatabase, Networkを1個だけDIする.Database, Networkを抽象化するクラス.例えば「サーバーからEntityをGETして,DatabaseにキャッシュしたあとにEntityを返す」といった処理を行う.
    • Database: Entityと1対1で対応.データベースの情報とEntityの変換を担当するクラス.実体はRoomのデータベースクラスで,DAOも提供する.
    • Network: Entityと1対1で対応.APIを介してサーバーからの情報をEntityに変換する(もしくはその逆を行う)クラス.実体はRetrofitのインターフェース.
    • Entity: データの実体.

クラス図を描くと多分こんな感じ.

クラス図

パッケージ構成

上記モジュール構成を元に,その他の要素を加えてパッケージ構成を作ってみます.

net.a4rcvv.myapp
|- di // HiltのDI用モジュールをまとめるパッケージ
||- RepositoryModule.kt
||- DatabaseModule.kt
||- ApiModule.kt
|- view
||- common // 共通して使われるUIなどを置く
|||- dialog
||||- AlertDialogFragment.kt
||- home // Activityごとにパッケージを分ける
|||- HomeActivity.kt
|||- HomeFragment.kt
|||- HomeViewModel.kt // Fragmentと一対一対応してるので,ViewModelも同階層に入れてしまう
|- usecase
||- LoginUseCase.kt
|- model
||- user // entity1つごとにパッケージを分ける
||- UserRepository.kt
||- UserDatabase.kt
||- UserApi.kt // RetrofitのInterface
||- UserEntity.kt // Data Class
|- utility // 汎用的に使われそうな処理を置く
||- PreferencesUtil.kt // 例えば,SharedPreferencesにアクセスするクラスなど
|- MyApplication.kt // Application Class

その他

Androidアプリ開発経験半年の人間が机上の空論で作ったものなので,色々おかしい点があるかもしれません(現時点では個人的に納得の行く構成ですが).実際に運用してみて変な点があったら追記します.

コメントする

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA