Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
あ
の
日
見
た
M
V
C	

を
僕
達
は
ま
だ
知
ら
な
い
for Ruby on Rails
このスライドはRailsMVC勉強会用のスライドです。
MVCについて歴史を遡って復習していき、
(一応RailsのMVCがテーマのイベントなので)
最終的にRailsのMVCについて考察することを目的としていま
す。
途中、議論の余地はあるが...
釘宮 愼之介
Engineer
@kgmyshin
釘宮 愼之介
最近はもっぱらAndroid(ぇ
・Model View Controllerの誕生	

・Smalltak-80でのMVC	

・Martin Fowlerの見解	

・MVC2の誕生	

・RailsのMVC
Model View Controllerの誕生
Trygve ReenskaugがXerox Parcで考案する
1979
Model View Controller Editorを考案
12 May 1979
Editorとは
Viewと入力デバイス間のinterfaceとなる
短命コンポーネント
数ヶ月の議論の末、
Model View Controllerとなった。
10 December 1979
EditorはControllerに吸収。
Models represent knowledge.
Modelとは知識を表す。(この知識って訳は微妙かも)
!
A view is a (visual) representation of its model.
ViewはModelの視覚的...
The essential purpose of MVC is to bridge the gap between the
human user's mental model and the digital model that exists ...
The structure is useful if the user needs to see the same model
element simultaneously in different contexts and/or from di...
Smalltalk-80でのMVC
TryvgeがXerox Parcを去った後
Jim Althoffらに依ってMVCを用いた
Smalltalk-80が実装される
1980年代
Smalltalk-80でのMVC
Model
The model of an application is the domain-specific software
simulation or implementation of the app...
Smalltalk-80でのMVC
View
views deal with everything graphical:
they request data from their model, and display the data.
Vie...
Smalltalk-80でのMVC
Controller
Controllers contain the interface between
their associated models and views
and the input dev...
Smalltalk-80でのMVC 補足
Broadcasting Change
In the scheme described above. views and controllers have
exactly one model. but ...
Smalltalk-80でのMVC 補足
全体像
via http://www.ics.uci.edu/ redmiles/ics227-SQ04/papers/KrasnerPope88.pdf
Martin Fowlerの見解
Martin Fowlerの見解抜粋
via http://martinfowler.com/eaaDev/uiArchs.html
MVCの肝はプレゼンテーション層と
ドメイン層を分けた事。
!
Model <->View, Controll...
Martin Fowlerの見解
MVCの問題点
via http://martinfowler.com/eaaDev/uiArchs.html
たとえば値が5以上だったときは赤
などのロジックはだれがもつべきか?
!
モデルから返ってくる値に...
Martin Fowlerの見解
MVCの問題点
via http://martinfowler.com/eaaDev/uiArchs.html
モデル
ViewController
モデルは
最悪プレゼンテーション層が
まるっと変わっても動く...
Martin Fowlerの見解
MVCの問題点の解決案
via http://martinfowler.com/eaaDev/uiArchs.html
モデル
ViewController
ドメイン層
プレゼンテーション層 プレゼンテーション...
MVC2の誕生
Sun MicrosystemsがJava Server Pageの仕様を
プレリリース
!
Model1とModel2があり、
そのModel2でMVCが使われた。
7 October 1998
JavaServerTM PagesTM - Specification 0.92
Model1 Model2
via http://www.javaworld.com/article/2076557/java-web-development/u...
ちなみにこれが縮まって MVC2 と言われている。
!
MVC version2!っていうわけではない。
RailsのMVC
すこし独特
ViewがModelと
直接やりとりをせず、
すべてControllerを通して行う
ただ、
プレゼンテーション層と
ドメイン層は分けるという
根本は変わらない。
Rails作成者のDHHも
Controllerにドメインロジックを
持つべきじゃないと言っている
RailsのMVCの個人的な違和感
ドメインロジックは
どこに書くべきか?
Q
A モデル
改めて、、、
rails generate model hoge
!
というコマンドを打つと
!
ActiveRecordを継承した
!
Hogeクラスができる
で、例えば、、、
ActiveRecordって
ドメインモデルそのもの?
違和感
ActiveRecordはORMであって、
それ以上でもそれ以下でもない。
ORM=ドメインモデルという場合もあるが、
多くはそうじゃない。
違和感に対する個人的な答え
プレゼンテーション層
ドメイン層
Controller View
Model
ここにドメイン
ロジックを
書くとfat controller
ActiveRecord
ActiveRecordに
書くべきでない
ドメインロジックを
書くとfat...
ActiveRecordはモデルの一部だけど、
そのものじゃないことが多いよね
というのを理解して
ドメインモデルを構築すべき。
実装における注意点
それ以降の話は
下記らへんが詳しい
中規模Web開発のためのMVC分割とレイヤアーキテクチャ
http://qiita.com/yuku_t/items/961194a5443b618a4cac
てめえらのRailsはオブジェクト指向じゃねえ!...
・めりはり(だれが何を担当しているか)が重要
・コンセプト(プレゼンテーション層とドメイン層の分離)の理解重要
・一度マーティンさんの記事を見ると理解深まるかも。
まとめ
・みんなMVCの理解が違いすぎるのでせめてチームでは合わせた方が良い
・...
fin.
Upcoming SlideShare
Loading in …5
×

あの日見たMVCを僕たちはまだ知らない for RoR

RoR用だけどRoRは最後にちょっと触れてるくらいです

  • Login to see the comments

あの日見たMVCを僕たちはまだ知らない for RoR

  1. 1. あ の 日 見 た M V C を 僕 達 は ま だ 知 ら な い for Ruby on Rails
  2. 2. このスライドはRailsMVC勉強会用のスライドです。 MVCについて歴史を遡って復習していき、 (一応RailsのMVCがテーマのイベントなので) 最終的にRailsのMVCについて考察することを目的としていま す。 途中、議論の余地はあるがわかりやすくするために 言い切っているところがあります。 構成微妙でごめんなさい。。じ、時間が。。 もっと意味ある構成にしたかった! AndroidとかiOSについても考察したかった! この資料の目的と注意
  3. 3. 釘宮 愼之介 Engineer @kgmyshin 釘宮 愼之介 最近はもっぱらAndroid(ぇ
  4. 4. ・Model View Controllerの誕生 ・Smalltak-80でのMVC ・Martin Fowlerの見解 ・MVC2の誕生 ・RailsのMVC
  5. 5. Model View Controllerの誕生
  6. 6. Trygve ReenskaugがXerox Parcで考案する 1979
  7. 7. Model View Controller Editorを考案 12 May 1979 Editorとは Viewと入力デバイス間のinterfaceとなる 短命コンポーネント
  8. 8. 数ヶ月の議論の末、 Model View Controllerとなった。 10 December 1979 EditorはControllerに吸収。
  9. 9. Models represent knowledge. Modelとは知識を表す。(この知識って訳は微妙かも) ! A view is a (visual) representation of its model. ViewはModelの視覚的な表示である。 ! A controller is the link between a user and the system. Controllerはユーザとシステムのリンクである。 Trygve Reenskaug曰く① via http://heim.ifi.uio.no/ trygver/1979/mvc-1/1979-05-MVC.pdf
  10. 10. The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. ! MVCの本質的な目的はユーザのメンタルモデルと コンピュータのデジタルモデルのギャップに 橋を架ける事。 Trygve Reenskaug曰く② via http://heim.ifi.uio.no/ trygver/themes/mvc/mvc-index.html
  11. 11. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints. ! この構造はユーザが違う立場、状況から 同じモデルを見るときに有効である。 Trygve Reenskaug曰く③ via http://heim.ifi.uio.no/ trygver/themes/mvc/mvc-index.html
  12. 12. Smalltalk-80でのMVC
  13. 13. TryvgeがXerox Parcを去った後 Jim Althoffらに依ってMVCを用いた Smalltalk-80が実装される 1980年代
  14. 14. Smalltalk-80でのMVC Model The model of an application is the domain-specific software simulation or implementation of the application's central structure. This can be as simple as an integer (as the model of a counter) or string (as the model of a text editor). or it can be a complex object. Modelはドメインのシミュレーションもしくは アプリの中心的な構造の実装である。 カウンターのModelであれば 単純なintegerそのものでもありえるし、 テキストエディターであるのならStringそのものでもありえるし、 また複雑なオブジェクトにもなり得る。
  15. 15. Smalltalk-80でのMVC View views deal with everything graphical: they request data from their model, and display the data. Viewは視覚的なすべてを扱う。 モデルにデータをリクエストして、それを表示する。
  16. 16. Smalltalk-80でのMVC Controller Controllers contain the interface between their associated models and views and the input devices (keyboard, pointing device, time). Controllers also deal with scheduling interactions with other view-controller pairs ControllerはModel、View、入力デバイス間の インターフェースを持つ。 またほかのView-Controllerペア間のスケジューリングも扱う。
  17. 17. Smalltalk-80でのMVC 補足 Broadcasting Change In the scheme described above. views and controllers have exactly one model. but a model can have one or several views and controllers associated with it. To maximize data encapsulation and thus code reusability. views and controllers need to know about their model explicitly. but models should not know about their views and controllers. A change in a model is often triggered by a controller connecting a user action to a message sent to the model. This change should be reflected in all of its views. not just the view associated with the controller that initiated the change. ControllerとViewは一つのModelをもつが、 Modelは複数のViewやControllerを持つ事ができる。 ControllerとViewはModelであると明確に知っている必要があるが Modelは彼らがControllerやViewであると知っている必要はない。 あるControllerからModelに通知がいき変化があったとき、 その変化はそのControllerに付随するViewだけでなく全てのViewに 通知されるべき。
  18. 18. Smalltalk-80でのMVC 補足 全体像 via http://www.ics.uci.edu/ redmiles/ics227-SQ04/papers/KrasnerPope88.pdf
  19. 19. Martin Fowlerの見解
  20. 20. Martin Fowlerの見解抜粋 via http://martinfowler.com/eaaDev/uiArchs.html MVCの肝はプレゼンテーション層と ドメイン層を分けた事。 ! Model <->View, Controller間の実装には オブザーバーパターンが有効。
  21. 21. Martin Fowlerの見解 MVCの問題点 via http://martinfowler.com/eaaDev/uiArchs.html たとえば値が5以上だったときは赤 などのロジックはだれがもつべきか? ! モデルから返ってくる値に依るが、 色はドメインとは関わりがない でどっちつかず。
  22. 22. Martin Fowlerの見解 MVCの問題点 via http://martinfowler.com/eaaDev/uiArchs.html モデル ViewController モデルは 最悪プレゼンテーション層が まるっと変わっても動くべきだから ここに色のロジックは持つべきじゃない ドメイン層 プレゼンテーション層 イベント処理しか したくない モデルのデータを 反映するだけで 複雑なロジックは持ちたくない
  23. 23. Martin Fowlerの見解 MVCの問題点の解決案 via http://martinfowler.com/eaaDev/uiArchs.html モデル ViewController ドメイン層 プレゼンテーション層 プレゼンテーションモデル プレゼンテーション層専用の モデルを作り ロジックはここで持つ
  24. 24. MVC2の誕生
  25. 25. Sun MicrosystemsがJava Server Pageの仕様を プレリリース ! Model1とModel2があり、 そのModel2でMVCが使われた。 7 October 1998
  26. 26. JavaServerTM PagesTM - Specification 0.92 Model1 Model2 via http://www.javaworld.com/article/2076557/java-web-development/understanding-javaserver-pages-model-2-architecture.html
  27. 27. ちなみにこれが縮まって MVC2 と言われている。 ! MVC version2!っていうわけではない。
  28. 28. RailsのMVC
  29. 29. すこし独特 ViewがModelと 直接やりとりをせず、 すべてControllerを通して行う
  30. 30. ただ、 プレゼンテーション層と ドメイン層は分けるという 根本は変わらない。
  31. 31. Rails作成者のDHHも Controllerにドメインロジックを 持つべきじゃないと言っている
  32. 32. RailsのMVCの個人的な違和感
  33. 33. ドメインロジックは どこに書くべきか? Q A モデル 改めて、、、
  34. 34. rails generate model hoge ! というコマンドを打つと ! ActiveRecordを継承した ! Hogeクラスができる で、例えば、、、
  35. 35. ActiveRecordって ドメインモデルそのもの? 違和感
  36. 36. ActiveRecordはORMであって、 それ以上でもそれ以下でもない。 ORM=ドメインモデルという場合もあるが、 多くはそうじゃない。 違和感に対する個人的な答え
  37. 37. プレゼンテーション層 ドメイン層 Controller View Model ここにドメイン ロジックを 書くとfat controller ActiveRecord ActiveRecordに 書くべきでない ドメインロジックを 書くとfat model アンチパターン
  38. 38. ActiveRecordはモデルの一部だけど、 そのものじゃないことが多いよね というのを理解して ドメインモデルを構築すべき。 実装における注意点
  39. 39. それ以降の話は 下記らへんが詳しい 中規模Web開発のためのMVC分割とレイヤアーキテクチャ http://qiita.com/yuku_t/items/961194a5443b618a4cac てめえらのRailsはオブジェクト指向じゃねえ!まずはCallbackクラス、 Validatorクラスを活用しろ! http://qiita.com/joker1007/items/2a03500017766bdb0234 http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ 7 Patterns to Refactor Fat ActiveRecord Models
  40. 40. ・めりはり(だれが何を担当しているか)が重要 ・コンセプト(プレゼンテーション層とドメイン層の分離)の理解重要 ・一度マーティンさんの記事を見ると理解深まるかも。 まとめ ・みんなMVCの理解が違いすぎるのでせめてチームでは合わせた方が良い ・ツイッターにDHHやマーティンさんいるのでfollowしておくと良いかも ・ケンゼンな設計とは?を常に意識したい ・ただ、MVCだけでなくMVVMなど他の設計思想もちゃんと理解したい 雑感
  41. 41. fin.

×