1. ぼくがかんがえた
さいきょうの
MVC
id:karupanerura
13年9月20日金曜日

2. だれ？
かるぱねるら(karupanerura)
Perl, JS, Java, elisp, zsh
ソーシャルゲーム開発者
Mobile Factory, Inc.
Chiba.pm
13年9月20日金曜日

3. Author (PAUSE: KARUPA)
Plack::Middleware::HTMLLint
Filesys::Notify::KQueue
AnyEvent::ForkManager
Contribute
Teng
CPAN
13年9月20日金曜日

4. MVCおさらい！
13年9月20日金曜日

5. MODEL
ビジネスロジック
アプリケーション機能
(データベース操作)
データの変更の通知
ex) Backbone.Model
WebAppは例外
13年9月20日金曜日

6. VIEW
UI出力
データの整形
データの変換
ex) Template
13年9月20日金曜日

7. CONTROLLER
UI入力
入力をModel/Viewに受け渡す
Modelの結果をViewに通知する
WebAppなど
13年9月20日金曜日

8. 本題
13年9月20日金曜日

9. MVC意外と
むずかしくないですか？
13年9月20日金曜日

10. 個人的MVCあるある
ふぇぇ…超巨大Modelができちゃったよぉ……。
SQLが色々な所に書いてあってカオス。
気付いたらControllerでもModelでも同じデータをfetchし
てたけどどっちにまとめるべきだろう…。
ViewがJSONとHTML両方あるんだけど…。
というか急にJSONが増えたんだけど…。
13年9月20日金曜日

11. こういうの
なくしたいですよね
13年9月20日金曜日

12. 今日はなすこと
MVCはそのまま使わない
MVCのカスタマイズ
チーム内規約をつくろう
まとめ
13年9月20日金曜日

13. MVCは
そのまま使わない
13年9月20日金曜日

14. MVCの定義は抽象的
対して、アプリケーションの種類は多い
Client Application
Web Application
API Server Application
そのままMVCを適用するとカオスになりがち
定義が曖昧な部分がブレる
13年9月20日金曜日

15. MVCのカスタマイズ
13年9月20日金曜日

16. なぜやるか
MVCの定義が曖昧な部分を明確にする
アプリケーションにMVCを最適化する
WebAppならWebAppのMVC
SocialAppならSocialAppのMVC
規則がはっきりしたコードが書きやすくなる
MVCの本来の目的の達成
13年9月20日金曜日

17. 具体例
Web Applicationの場合
13年9月20日金曜日

18. WebAppの特徴(1)
入力がいろいろある
HTTP Header / Request Parameter / Cool URI /
etc...
うまい具合に吸収して統一しないと扱いにくい
出力もいろいろある
HTML / JSON / MessagePack / XML / etc...
13年9月20日金曜日

19. WebAppの特徴(2)
リクエスト毎にしか状態が無い
DBと組み合わせる必要がある
大量のリクエストを捌きたいケースも多い
キャッシュも考慮した仕組みが必要
アプリケーションの機能が膨大になるケースも
DB操作が多く煩雑になりがちなので分離して抽象化
13年9月20日金曜日

20. OVERVIEW
View
ControllerContext
Model DB
user
web service
request
response
13年9月20日金曜日

21. CONTEXT
リクエスト単位を管理するクラス
リクエスト毎にインスタンスを生成
ex) Amon2::Web
リクエスト単位での状態遷移とリソースを管理する
基本的にはここにアプリケーションロジックは書かない
13年9月20日金曜日

22. CONTROLLER
リクエストで渡されたデータを整理してModelに引き渡す
ビジネスロジックへの入力を抽象化する
入力の存在/型チェックの簡易Validationをする
Modelの結果をContext経由でViewに引き渡す
Modelの例外をcatchしてエラー処理を行う
Controllerを見ればリクエストのフローが全て見える
13年9月20日金曜日

23. MODEL
ビジネスロジックを抽象化する
目的に対して必要な処理を手続きとして実装
ビジネスロジックに依存するトランザクションも管理
カッチリしたValidationはここで行う
問題があればExceptionでControllerに通知
Modelを見ればアプリケーションの機能が分かる
13年9月20日金曜日

24. DB
データベース操作を抽象化する
SQLもこの名前空間で整理する
目的に対して必要なDB操作を手続きとして実装する
ex) DBIx::Sunny::Schema
DBを見ればデータベースをどのように操作するかが分かる
schemaのチューニングやDBキャッシュが容易になる
13年9月20日金曜日

25. VIEW
渡されたデータを素に出力を整形する
JSONならJSON向けにdeflateする役割もここが担う
HTMLならTemplateなど
複数のViewで統一したインターフェースを提供する
Viewクラスを差し替える事を容易に
Viewをみればデータをどのように整形するか分かる
13年9月20日金曜日

26. CACHE POINT
View
ControllerContext
Model DB
user
web service
request
response
13年9月20日金曜日

27. 小まとめ
アプリケーションの要件毎に性質を分析しMVCを最適化
今回はWebAppという大きな括りでやったが実際は更に
細かく要件を絞る
MVCの曖昧な部分をアプリケーションに合わせて具体化
13年9月20日金曜日

28. いいかんじっぽい！
13年9月20日金曜日

29. まあでも
13年9月20日金曜日

30. 実現できなきゃ
意味無い！！
13年9月20日金曜日

31. チーム内規約をつくる
各名前空間の役割を規約化する
明文化していることでブレにくくなる
「やってはいけない事」も書く
具体例としてダメな例を併記しておくとベター
コードレビューで規約に沿っているか確認する
可能なら自動テストで簡易チェックも
13年9月20日金曜日

32. まとめ
MVCはそのまま使わない
用途に合わせて構成とフローを整理して再構築する
チーム内規約を作り、守る
コードレビューを定期的に実施して意識づくり
可能ならば自動テストで簡易チェックも
13年9月20日金曜日

33. あなたがかんがえた
さいきょうの
MVC
13年9月20日金曜日

34. おわり
Mobile FactoryではMVCが好きな人材を募集しております
13年9月20日金曜日