More than 5 years have passed since last update.

モバイルアプリアーキテクチャ勉強会

Last updated at 2017-04-21Posted at 2017-04-21

1 / 65

これは社内勉強会で利用した資料です。
そのため、語尾が雑だったり主観的な記述が多いですが、懐に眠らせておくよりは公開したほうが世のためになると考え、この記事を公開します。

この勉強会の目的

過去のアーキテクチャからナウいアーキテクチャまで一通り学ぶことで、今後の開発やリファクタリングの指針としたい。

アーキテクチャとは

MVC とか MVP とかの、ディレクトリ構成や各レイヤで何を担当するかなどの話です。
今回は特にモバイルアプリ、どちらかというと iOS よりの話です。

アーキテクチャは必要か？

標準に従うんじゃダメなの？

iOS

コントローラは UIViewController を継承する
- ViewController ...?
普通に書くと View と Controller がぐっちゃぐっちゃ
FatViewController へ...

import UIKit

class HogeViewController: UIViewController {
    @IBOutlet weak var tableView: UITableView!
    @IBOutlet weak var button: UIButton!

    override func viewDidLoad() {
        super.viewDidLoad()
    }

    @IBAction func buttonTapped(_ sender: AnyObject) {
        print("tap")
    }
}

Android

コントローラは Activity を継承する
普通に書くと Activity と View がぐっちゃぐっちゃ
FatActivity へ...

public class MainActivity extends Activity {
   @Override
   public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
      Log.d(msg, "The onCreate() event");
   }
}

つまり M-VC

iOS も Android も View と Controller がまとめられてる
M-VC なコードになる
- Model, ViewController という関係性
テストがかけない...

だから設計談義が盛り上がる

アーキテクチャを導入する目的

保守性の高いコード
- FatController にしない
- テストのかきやすい構成へ
考える時間/レビュー時間を減らす
- どの階層、ファイルで何をするか決めておく
規約と秩序！！！！！！！！！！！！

本題

アーキテクチャいろいろあります

MVC

原初 MVC

データの流れが一方方向、 Observer!

Model View Controller - Wikipedia

原初 MVC 問題点

Model が View にデータを送るが、 View は Model に依存した画面しか表示ができずつらい。
MVCモデルの問題点を解決するPMモデルとMVPモデル - GeekなNooblog

MVC2

Ruby on Rails チュートリアル：実例を使って Rails を学ぼう

MVC2

Controller は View と Model をつなぐ。
View と Model は直接繋がらない！ Controller を挟む。
- MVC と比べ View と Model の依存が解決された！
Fat Model

Cocoa MVC

Apple 様の提唱している MVC。

Objective-Cプログラミングの概念 (TP40010810 1.0)

Cocoa MVC

Model と Controller は Observer な関係。
やはり Controller の負担が大きすぎて Fat になる。
MCV を文字って Massive View Controller とか言われる。

サンプル
- ios-architectures/ios-architectures/MVC at master · tattn/ios-architectures

MVP

Model
- View と Presenter 以外
View
- ViewController も View に含む！！！！！ ここがポイント
Presenter
- View と Model を仲介する

つまり View は View に専念し、
Presenter がコントローラの枠割を担う

2 つの MVP

MVP と言っても 2 つあります

ややこしい

MVP (Supervising Controller)
MVP (Passive View)

MVP (Supervising Controller)

Supervising Controller

MVP (Supervising Controller)

原初 MVC とにてる、 Model が更新されたら View が更新される。
- View と Model はデータバインディングする
- View と Model が依存関係になるため簡単に Model や View を変えられないなど問題がある
  - View と Model に依存は持ちたくないのでこれは使いたくない

MVP (Passive View)

Dot Net Facts: The MVP pattern

MVP (Passive View)

処理の流れ(MVC2 とにてる)
- View のイベントを Presenter に渡す
- Presenter が Model に処理を依頼
- Model が処理して Presenter に返す
- Presenter が View に渡す
- View はそれを表示する

MVP (Passive View)

View と Model が依存していない
Presenter は View がどう描画されるか知らない
- Presenter に import UIKit を書いてはいけない！！
- だから概念的には iOS でも Mac アプリでも同じ Presenter を使える
サンプル
- iyadagha/iOS-mvp-sample

MVP (Passive View)

Passive View 良いと思います。
- 今後新規アプリを作る時は少なくとも MVP は欲しい
- わかりやすいので学習コストが少ない
- Presenter のテストがかける
  - view のテストは...
Presenter が大きくなりがちだけどそういうもんじゃね？

MVP 2つありますが、これ以降の MVP という単語は Passive View を指します。

MVVM

発祥は Microsoft

MVVMパターンは、2006年11月21日にリリースされた.NET Framework 3.0に実装されたWPFとSilverlightの両方をサポートするために考案された。
Model View ViewModel - Wikipedia

MVVM

Model View ViewModel - Wikipedia

MVVM

データバインディングが必須
- ユーザが文字を入力する
- 入力された文字が自動で ViewModel に連携される (binding)
- ViewModel が Model に変更依頼
- Model でなんか処理する
  - 変更は通知で伝える
- ViewModel の値が変わると自動で View も変わる (binding)
MVP でデータバインディングを使うと ViewModel になる感じ

変更は通知で伝える

MVVMのModelにまつわる誤解 - the sea of fertility

ViewModel は戻り値のない Model のメソッドを叩くだけ
- 返り値は受け取らない
ViewModel は Model の変更を Observe する
- Model は変更を ViewModel に通知する

ひたすら Observable を使う感じ...

ライブラリが必須

RxSwift, RxJava などのライブラリが必要
ひたすら依存度が高い、Rx が死んだらアプリも死ぬ (かも)
- 恐怖！忍び寄るライブラリへのロックイン - Qiita
学習コストが高い
- RxSwift やってるけどめっちゃむずい...

MVVM は今までとパラダイムが全然違う

RxSwift は Functional Reactive Programing
- 今までの命令型とは全然違う
- 関数型で宣言的に書いていく
- ちょっと入れてみるか〜という感じではない

しかしアツい

#DroidKaigi サイバーエージェントブースにお越しくださった皆様、二日間ありがとうございました🙏アンケートの最終結果はこちらです👇 ✨ pic.twitter.com/UlhOd5uk6t
— CyberAgentDevelopers (@ca_developers) 2017年3月10日

向き不向きを見極めて使う

本当に MVVM が必要か考えて使うべき
- ノリで使ってはならない！
向いているもの
- ユーザアクションの多いものや Reactive なアプリケーション
  - 例えば LINE みたいなのとか、電卓とか
  - (ユーザアクションが少ないアプリなど存在しないのでは...?)
導入に当たって現状の課題を考える
- 状態を変数で持つのが苦しいか？
- データバインディングが欲しいか？
- Observable が求められているか？
学習コストは高いぞ

良い資料

VIPER

iOS Project Architecture: Using VIPER | Cheesecake Labs

VIPER 用語

View(UIVIewVontroller)
- ボタンをしたのを Presenter に伝える
Presenter
- Interactor, Router, View などの橋渡し
Router
- Dependency Injection と画面遷移
Interactor
- API の実行やデータの fetch など
DataManager
- VIPER の文字の中には出てこない、あってもなくても良い
- Interactor が直接データを触らないようにする
Entity
- データオブジェクト、データ型定義みたいなやつ

これらを 1 つのモジュール(画面)として管理

VIPER のキモは Router

モジュールは全て interface をきり interface に従い実装する
それぞれのモジュールは実装に依存せず interface に依存する
抽象に依存した実装になる
Router がモジュールに対し依存性を注入する
- テストがかける！！！！！！！！！！

メリデメ

すべて Protocol (Interface) を作るので、モック化しやすい
ファイル数が多い
- generator みたいなのがある: rambler-digital-solutions/Generamba: This codegenerator is too brilliant to be real!
規律と秩序
- Presenter, Interactor などどう実装するかメンバーで認識の齟齬が起きにくい
- 抽象に依存した実装になるためモック化がしやすい

VIPER or not

#8 VIPER to be or not to be? – swifting.io

資料

Clean Architecture

VIPER をもっと厳密にしたやつ、 Layerd Architecture などと呼ばれる

クリーンアーキテクチャ(The Clean Architecture翻訳)

構成

まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて - Qiita

ファイル数やばい

bannzai/Kuri: Automatically generates necessary code for iOS CleanArchitecture and imports it into Xcode project.

やばいので解説しない

どういう時に使うか

長期にわたる開発・メンテナンスが必要になるとき

複雑な機能を有するアプリを開発するとき

テストを重視した開発のとき

長期というのは、クリーンアーキテクチャを案件に導入してみたことのある人々の間でだいたい1年以上
Clean Architectureとその派生系による最適なiOSアーキテクチャ選定の考察｜ Developers.IO

(メンテ含めて1年超えないアプリなど存在しないのでは？)

開発メンバーが2,3人でやるには大げさなきがするので、やるとしてもこれから削って必要のなのを見極めた方が良さそう。

資料

Flux

データの流れが一方方向！

facebook/flux: Application Architecture for Building User Interfaces

Flux

原初 MVC も一方方向でしたね
ぐるぐる回るよ〜
DOM の反映は差分検知で React がよろしくやってくれる
- iOS にも Android にも React はない
  - ライブラリ入れるか〜？
データの一方方向などの考え方はめっちゃいいと思うけど、ライフサイクルなどが標準と離れすぎてる気が
Flux したいなら ReactNative 使えば？
こんなクソ記事を書いていた時期もあった
- React + Redux + TypeScript でWebアプリを作った感想・勉強法と Angular との比較 - Qiita

DDD

ドメイン駆動設計は特定のアーキテクチャに依存しているものではありません。
Y.A.M の雑記帳: ドメイン駆動設計について DroidKaigi 2017 で登壇しました。

なので解説しません。

そのた

多分他にもいっぱいある

まとめ (個人の意見)

MVP は絶対に欲しい
MVVM は検討した上で導入
VIPER の DI の思想は良いので導入したい
- Clean Architecture は重すぎるので VIPER より厳格に決めたいと思ってから入れたい
まずは MVVM や VIPER がどれほどのものか 実際に何か作る ことが必要と思う
あなたの開発、Hype(誇大宣伝) Driven Development になっていませんか？ - Qiita

わかりやすい資料

最初からこれよんだ方がわかりやすいのでは？

ほか参考

質問

アーキテクチャを途中で変えたりはできるのか？

MVC -> MVP とかは Presenter 作るだけ、 VIPER も既存のを分割するので難しくない。
ただし、 MVVM -> MVP とかは作り直しのレベルになる。

いまのあなたのアプリはどうなの？

MVC でできてる。正直ミスった。
しかも MVC の C と M のやりとりを callback でやっている。
半年前は勉強不足だった。

Flux 良さそうじゃない？

Store を変えれば View が変わるの良さそう。
Web フロントエンドの人曰くガチの Flux はややこしいので必要な部分をかいつまんでやるのが良いとのこと。

React-Native やっていきたい。

そもそもなぜ Apple は View と Controller を一緒にしているのか

storyboard と紐付くのが ViewController だから。
また、学習コストがとても低い。
入門書に Presenter などは出てこない。

アーキテクチャが目的にならないようにしたいね

その通り。

画像など問題ありましたら消します。

273

222

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up