あの日見た

MVC を

僕達はまだ

知らない

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 ChangeIn 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.