SlideShare a Scribd company logo
1 of 41
Download to read offline
あ
の
日
見
た
M
V
C	

を
僕
達
は
ま
だ
知
ら
な
い
for Ruby on Rails
このスライドはRailsMVC勉強会用のスライドです。
MVCについて歴史を遡って復習していき、
(一応RailsのMVCがテーマのイベントなので)
最終的にRailsのMVCについて考察することを目的としていま
す。
途中、議論の余地はあるがわかりやすくするために
言い切っているところがあります。
構成微妙でごめんなさい。。じ、時間が。。
もっと意味ある構成にしたかった!
AndroidとかiOSについても考察したかった!
この資料の目的と注意
釘宮 愼之介
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の視覚的な表示である。
!
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
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
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
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 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そのものでもありえるし、
また複雑なオブジェクトにもなり得る。
Smalltalk-80でのMVC
View
views deal with everything graphical:
they request data from their model, and display the data.
Viewは視覚的なすべてを扱う。
モデルにデータをリクエストして、それを表示する。
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ペア間のスケジューリングも扱う。
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に
通知されるべき。
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, Controller間の実装には
オブザーバーパターンが有効。
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/understanding-javaserver-pages-model-2-architecture.html
ちなみにこれが縮まって 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 model
アンチパターン
ActiveRecordはモデルの一部だけど、
そのものじゃないことが多いよね
というのを理解して
ドメインモデルを構築すべき。
実装における注意点
それ以降の話は
下記らへんが詳しい
中規模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
・めりはり(だれが何を担当しているか)が重要
・コンセプト(プレゼンテーション層とドメイン層の分離)の理解重要
・一度マーティンさんの記事を見ると理解深まるかも。
まとめ
・みんなMVCの理解が違いすぎるのでせめてチームでは合わせた方が良い
・ツイッターにDHHやマーティンさんいるのでfollowしておくと良いかも
・ケンゼンな設計とは?を常に意識したい
・ただ、MVCだけでなくMVVMなど他の設計思想もちゃんと理解したい
雑感
fin.

More Related Content

What's hot

ゲームエンジンとMVC
ゲームエンジンとMVCゲームエンジンとMVC
ゲームエンジンとMVC
AimingStudy
 
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツオブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
 

What's hot (20)

導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来について
 
Iocコンテナについて
IocコンテナについてIocコンテナについて
Iocコンテナについて
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
 
serviceクラスをやめようサブクラスを使おう
serviceクラスをやめようサブクラスを使おうserviceクラスをやめようサブクラスを使おう
serviceクラスをやめようサブクラスを使おう
 
Dockerを支える技術
Dockerを支える技術Dockerを支える技術
Dockerを支える技術
 
ゲームエンジンとMVC
ゲームエンジンとMVCゲームエンジンとMVC
ゲームエンジンとMVC
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
MvcのFatモデルに立ち向かう
MvcのFatモデルに立ち向かうMvcのFatモデルに立ち向かう
MvcのFatモデルに立ち向かう
 
Oss貢献超入門
Oss貢献超入門Oss貢献超入門
Oss貢献超入門
 
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
 
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
 
Laravelを用いたゲームサーバーのチューニング
Laravelを用いたゲームサーバーのチューニングLaravelを用いたゲームサーバーのチューニング
Laravelを用いたゲームサーバーのチューニング
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツオブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
 

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

090821 Ruby Sapporo Night Ruby Cocoa
090821 Ruby Sapporo Night Ruby Cocoa090821 Ruby Sapporo Night Ruby Cocoa
090821 Ruby Sapporo Night Ruby Cocoa
Tomoki Maeda
 
【アジャイル道場】Rails勉強会(view編)
【アジャイル道場】Rails勉強会(view編)【アジャイル道場】Rails勉強会(view編)
【アジャイル道場】Rails勉強会(view編)
Sosuke Kimura
 
20130316 mix cpp-yuo
20130316 mix cpp-yuo20130316 mix cpp-yuo
20130316 mix cpp-yuo
OKUBO_Yusuke
 
Spring mvc
Spring mvcSpring mvc
Spring mvc
Ryo Asai
 
TableViewAgent
TableViewAgentTableViewAgent
TableViewAgent
Akura Pi
 

Similar to あの日見たMVCを僕たちはまだ知らない for RoR (20)

T35 ASP.NET MVCを使ったTDD入門
T35 ASP.NET MVCを使ったTDD入門T35 ASP.NET MVCを使ったTDD入門
T35 ASP.NET MVCを使ったTDD入門
 
Mvc conf session_1_osada
Mvc conf session_1_osadaMvc conf session_1_osada
Mvc conf session_1_osada
 
MVVM入門
MVVM入門MVVM入門
MVVM入門
 
090821 Ruby Sapporo Night Ruby Cocoa
090821 Ruby Sapporo Night Ruby Cocoa090821 Ruby Sapporo Night Ruby Cocoa
090821 Ruby Sapporo Night Ruby Cocoa
 
ASP.NET MVC と jQuery で実践する標準志向 Web 開発
ASP.NET MVC と jQuery で実践する標準志向 Web 開発ASP.NET MVC と jQuery で実践する標準志向 Web 開発
ASP.NET MVC と jQuery で実践する標準志向 Web 開発
 
MVCのつぎは・・・
MVCのつぎは・・・MVCのつぎは・・・
MVCのつぎは・・・
 
ASP.NET MVC 1.0
ASP.NET MVC 1.0ASP.NET MVC 1.0
ASP.NET MVC 1.0
 
ASP.NET MVC 2 ~新機能の紹介~
ASP.NET MVC 2 ~新機能の紹介~ASP.NET MVC 2 ~新機能の紹介~
ASP.NET MVC 2 ~新機能の紹介~
 
【アジャイル道場】Rails勉強会(view編)
【アジャイル道場】Rails勉強会(view編)【アジャイル道場】Rails勉強会(view編)
【アジャイル道場】Rails勉強会(view編)
 
20130316 mix cpp-yuo
20130316 mix cpp-yuo20130316 mix cpp-yuo
20130316 mix cpp-yuo
 
Slide
SlideSlide
Slide
 
PHP勉強会 #51
PHP勉強会 #51PHP勉強会 #51
PHP勉強会 #51
 
RIAアーキテクチャー研究会 第3回 セッション4 Mvpvm pattern
RIAアーキテクチャー研究会 第3回 セッション4 Mvpvm patternRIAアーキテクチャー研究会 第3回 セッション4 Mvpvm pattern
RIAアーキテクチャー研究会 第3回 セッション4 Mvpvm pattern
 
Mvpvm pattern
Mvpvm patternMvpvm pattern
Mvpvm pattern
 
Rails基礎講座 part.2
Rails基礎講座 part.2Rails基礎講座 part.2
Rails基礎講座 part.2
 
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
今こそ知りたいSpring Web(Spring Fest 2020講演資料)今こそ知りたいSpring Web(Spring Fest 2020講演資料)
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
 
Xamarin.formsでのmvvm利用のコツ
Xamarin.formsでのmvvm利用のコツXamarin.formsでのmvvm利用のコツ
Xamarin.formsでのmvvm利用のコツ
 
Separate Model from Catalyst
Separate Model from CatalystSeparate Model from Catalyst
Separate Model from Catalyst
 
Spring mvc
Spring mvcSpring mvc
Spring mvc
 
TableViewAgent
TableViewAgentTableViewAgent
TableViewAgent
 

More from shinnosuke kugimiya

More from shinnosuke kugimiya (12)

Coordinator Layout Behavior
Coordinator Layout BehaviorCoordinator Layout Behavior
Coordinator Layout Behavior
 
Framework code reading
Framework code readingFramework code reading
Framework code reading
 
読むと怖くないDagger2
読むと怖くないDagger2読むと怖くないDagger2
読むと怖くないDagger2
 
このあと滅茶苦茶LGTMした
このあと滅茶苦茶LGTMしたこのあと滅茶苦茶LGTMした
このあと滅茶苦茶LGTMした
 
just one line
just one linejust one line
just one line
 
これからの設計の話をしよう
これからの設計の話をしようこれからの設計の話をしよう
これからの設計の話をしよう
 
例の縛るやつ(Data binding)
例の縛るやつ(Data binding)例の縛るやつ(Data binding)
例の縛るやつ(Data binding)
 
Android Architecture
Android ArchitectureAndroid Architecture
Android Architecture
 
KotlinつかってQiitaクライアント作った時の話
KotlinつかってQiitaクライアント作った時の話KotlinつかってQiitaクライアント作った時の話
KotlinつかってQiitaクライアント作った時の話
 
Model View Presenter for Android
Model View Presenter for AndroidModel View Presenter for Android
Model View Presenter for Android
 
開発効率アンチパターン
開発効率アンチパターン開発効率アンチパターン
開発効率アンチパターン
 
Reactive android
Reactive androidReactive android
Reactive android
 

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