ぼくがかんがえたさいきょうのMvc

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

だれ？
かるぱねるら(karupanerura)
Perl, JS, Java, elisp, zsh
ソーシャルゲーム開発者
Mobile Factory, Inc.
Chiba.pm

Author (PAUSE: KARUPA)
Plack::Middleware::HTMLLint
Filesys::Notify::KQueue
AnyEvent::ForkManager
Contribute
Teng
CPAN

MVCおさらい！

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

VIEW
UI出力
データの整形
データの変換
ex) Template

CONTROLLER
UI入力
入力をModel/Viewに受け渡す
Modelの結果をViewに通知する
WebAppなど

本題

MVC意外と
むずかしくないですか？

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

こういうの
なくしたいですよね

今日はなすこと
MVCはそのまま使わない
MVCのカスタマイズ
チーム内規約をつくろう
まとめ

MVCは
そのまま使わない

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

MVCのカスタマイズ

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

具体例
Web Applicationの場合

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

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

OVERVIEW
View
ControllerContext
Model DB
user
web service
request
response

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

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

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

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

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

CACHE POINT
View
ControllerContext
Model DB
user
web service
request
response

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

いいかんじっぽい！

まあでも

実現できなきゃ
意味無い！！

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

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

あなたがかんがえた
さいきょうの
MVC

おわり
Mobile FactoryではMVCが好きな人材を募集しております

ぼくがかんがえたさいきょうのMvc

More Related Content

Viewers also liked (20)

Similar to ぼくがかんがえたさいきょうのMvc (20)

More from karupanerura (20)

ぼくがかんがえたさいきょうのMvc