ぼくがかんがえたさいきょうのMvc

12,478 views

Published on

0 Comments
32 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,478
On SlideShare
0
From Embeds
0
Number of Embeds
2,364
Actions
Shares
0
Downloads
41
Comments
0
Likes
32
Embeds 0
No embeds

No notes for slide

ぼくがかんがえたさいきょうのMvc

  1. 1. ぼくがかんがえた さいきょうの MVC id:karupanerura 13年9月20日金曜日
  2. 2. だれ? かるぱねるら(karupanerura) Perl, JS, Java, elisp, zsh ソーシャルゲーム開発者 Mobile Factory, Inc. Chiba.pm 13年9月20日金曜日
  3. 3. Author (PAUSE: KARUPA) Plack::Middleware::HTMLLint Filesys::Notify::KQueue AnyEvent::ForkManager Contribute Teng CPAN 13年9月20日金曜日
  4. 4. MVCおさらい! 13年9月20日金曜日
  5. 5. MODEL ビジネスロジック アプリケーション機能 (データベース操作) データの変更の通知 ex) Backbone.Model WebAppは例外 13年9月20日金曜日
  6. 6. VIEW UI出力 データの整形 データの変換 ex) Template 13年9月20日金曜日
  7. 7. CONTROLLER UI入力 入力をModel/Viewに受け渡す Modelの結果をViewに通知する WebAppなど 13年9月20日金曜日
  8. 8. 本題 13年9月20日金曜日
  9. 9. MVC意外と むずかしくないですか? 13年9月20日金曜日
  10. 10. 個人的MVCあるある ふぇぇ…超巨大Modelができちゃったよぉ……。 SQLが色々な所に書いてあってカオス。 気付いたらControllerでもModelでも同じデータをfetchし てたけどどっちにまとめるべきだろう…。 ViewがJSONとHTML両方あるんだけど…。 というか急にJSONが増えたんだけど…。 13年9月20日金曜日
  11. 11. こういうの なくしたいですよね 13年9月20日金曜日
  12. 12. 今日はなすこと MVCはそのまま使わない MVCのカスタマイズ チーム内規約をつくろう まとめ 13年9月20日金曜日
  13. 13. MVCは そのまま使わない 13年9月20日金曜日
  14. 14. MVCの定義は抽象的 対して、アプリケーションの種類は多い Client Application Web Application API Server Application そのままMVCを適用するとカオスになりがち 定義が曖昧な部分がブレる 13年9月20日金曜日
  15. 15. MVCのカスタマイズ 13年9月20日金曜日
  16. 16. なぜやるか MVCの定義が曖昧な部分を明確にする アプリケーションにMVCを最適化する WebAppならWebAppのMVC SocialAppならSocialAppのMVC 規則がはっきりしたコードが書きやすくなる MVCの本来の目的の達成 13年9月20日金曜日
  17. 17. 具体例 Web Applicationの場合 13年9月20日金曜日
  18. 18. WebAppの特徴(1) 入力がいろいろある HTTP Header / Request Parameter / Cool URI / etc... うまい具合に吸収して統一しないと扱いにくい 出力もいろいろある HTML / JSON / MessagePack / XML / etc... 13年9月20日金曜日
  19. 19. WebAppの特徴(2) リクエスト毎にしか状態が無い DBと組み合わせる必要がある 大量のリクエストを捌きたいケースも多い キャッシュも考慮した仕組みが必要 アプリケーションの機能が膨大になるケースも DB操作が多く煩雑になりがちなので分離して抽象化 13年9月20日金曜日
  20. 20. OVERVIEW View ControllerContext Model DB user web service request response 13年9月20日金曜日
  21. 21. CONTEXT リクエスト単位を管理するクラス リクエスト毎にインスタンスを生成 ex) Amon2::Web リクエスト単位での状態遷移とリソースを管理する 基本的にはここにアプリケーションロジックは書かない 13年9月20日金曜日
  22. 22. CONTROLLER リクエストで渡されたデータを整理してModelに引き渡す ビジネスロジックへの入力を抽象化する 入力の存在/型チェックの簡易Validationをする Modelの結果をContext経由でViewに引き渡す Modelの例外をcatchしてエラー処理を行う Controllerを見ればリクエストのフローが全て見える 13年9月20日金曜日
  23. 23. MODEL ビジネスロジックを抽象化する 目的に対して必要な処理を手続きとして実装 ビジネスロジックに依存するトランザクションも管理 カッチリしたValidationはここで行う 問題があればExceptionでControllerに通知 Modelを見ればアプリケーションの機能が分かる 13年9月20日金曜日
  24. 24. DB データベース操作を抽象化する SQLもこの名前空間で整理する 目的に対して必要なDB操作を手続きとして実装する ex) DBIx::Sunny::Schema DBを見ればデータベースをどのように操作するかが分かる schemaのチューニングやDBキャッシュが容易になる 13年9月20日金曜日
  25. 25. VIEW 渡されたデータを素に出力を整形する JSONならJSON向けにdeflateする役割もここが担う HTMLならTemplateなど 複数のViewで統一したインターフェースを提供する Viewクラスを差し替える事を容易に Viewをみればデータをどのように整形するか分かる 13年9月20日金曜日
  26. 26. CACHE POINT View ControllerContext Model DB user web service request response 13年9月20日金曜日
  27. 27. 小まとめ アプリケーションの要件毎に性質を分析しMVCを最適化 今回はWebAppという大きな括りでやったが実際は更に 細かく要件を絞る MVCの曖昧な部分をアプリケーションに合わせて具体化 13年9月20日金曜日
  28. 28. いいかんじっぽい! 13年9月20日金曜日
  29. 29. まあでも 13年9月20日金曜日
  30. 30. 実現できなきゃ 意味無い!! 13年9月20日金曜日
  31. 31. チーム内規約をつくる 各名前空間の役割を規約化する 明文化していることでブレにくくなる 「やってはいけない事」も書く 具体例としてダメな例を併記しておくとベター コードレビューで規約に沿っているか確認する 可能なら自動テストで簡易チェックも 13年9月20日金曜日
  32. 32. まとめ MVCはそのまま使わない 用途に合わせて構成とフローを整理して再構築する チーム内規約を作り、守る コードレビューを定期的に実施して意識づくり 可能ならば自動テストで簡易チェックも 13年9月20日金曜日
  33. 33. あなたがかんがえた さいきょうの MVC 13年9月20日金曜日
  34. 34. おわり Mobile FactoryではMVCが好きな人材を募集しております 13年9月20日金曜日

×