UniStudy#2　発表資料です。

1. MVC
FatModelに立ち向かう - 挑戦 -
(Railsベース)
Unicast Inc. Web Engineer
疋田 駿
UniStudy#2 @ シェアハウスコクリエ

2. 話す人
株式会社ユニキャスト セールスエンジニア
▷ 2015年入社の新卒文系Webエンジニア（23歳）
▷ Ruby, Ruby on Rails, PHP, AngularJS, WordPress
▷ Microservicesなサービス作り希望
http://qiita.com/shunhikita
https://twitter.com/shunhikita

3. 1.
そもそもMVCとは?
Model, View, Controller ?

4. “MVCは、ユーザインタフェースを持つアプリケーションを
実装するためのデザインパターンである。
内部データをユーザが直接参照・編集する
情報から分離する。
参照： Model View Controller - Wikipedia
https://ja.wikipedia.org/wiki/Model_View_Controller

5. ModelView
Controller
USER
ユーザのリクエストを受け取る
Modelにメッセージを送り
Modelからデータを受け取る
Viewにデータやメッセージを送り
生成されたHTMLやJSON等を受け取る
MVCはいろいろな意見があるので
あまり触れたくない。。。PushとかPullとか
Viewで生成したものを
Userに返す。
そのアプリケーションに関わる
ビジネスロジックを扱う
ユーザからのリクエストを扱う
ユーザとの接点となるビューを扱う

6. 2.
SkinnyController&FatModel
薄いコントローラ、厚いモデル

7. Controllerは便利です。
ControllerはViewともModelともUserとも全てとつな
がっています。
ModelView
Controller

8. そしてコントローラが肥大化します。
コントローラにビジネスロジック！？

9. だから
コントローラは薄く
（SkinnyController）しろ！
って言われてきましたね。

10. そして
Fatモデル です。
Modelは
ビジネスロジック全般の責任を
持ちます。
役割が多いんです。
（ここからはRails系の話です。）

11. ActiveRecord
▷ Railsでは基本的にModelを作成する ActiveRecord::Base を継承して
クラスが作成されます。
▷ ActiveRecordはActiveRecordパターンを実現するためのgemです。
▷ ActiveRecordはロジックとDBへの永続化をまとめてカプセル化し、
データにドメインロジックを追加します。
▷ CRUD+αくらいならこのクラスにドメインロジックを書いていくことで上手く行
きますが、中規模以上だと、ロジックが多くなり非常に辛くなります。
=> Fat Model!!
でもね、
Model = ActiveRecord じゃないよ。

12. 解決策
▷ ActiveRecordから責任を分離していくこと。
▷ それぞれの役割を分離するための仕組みがRailsには用意されています。
（流石Rails!!流石Ruby!!）
ダメ！絶対！
▷ 肥大化したActiveRecordクラスからメソッドをモジュールに移動して
ミックスインするの。
▷ 結局モデルにミックスインされるんだから変わらない。
▷ 見た感じ良くてなっても無理やり詰め仕込んだ感。。。結局一つのモデル
にたくさんの責務を持たせることに変わりはない。

13. 3.
Fatモデルに立ち向かう
ActiveRecordから仕事を奪え！
手探りで挑戦中です。みなさんのご意見下さい。

14. モデル分割
callbackクラス 汎用的なcallback対応メソッドの再利用
適切な名前付け
validatorクラス 汎用的なValidationの再利用
decoratorクラス それぞれのViewに適した表現はActiveRecordクラスで加工するので
なくdecoratorクラスで加工
formクラス 一つのフォームで複数のモデルを操作するなど、それ専用のクラスを
作ると表現方法が広がり無駄なビジネスロジックの記述が減る。
Parameterクラス フォームから送られてきたデータを modelやformオブジェクトに適した
形に変換したりバリデーションをかけたりするラッパのような存在。
Queryクラス スコープやクラスメソッド等が乱雑に定義された、複雑な SQLクエリや
汎用性のあるクエリは Queryクラスで行うと便利。
Searchクラス 検索は条件が同じ場合が多かったりするので、 Searchクラスを作ると
便利。クラスマクロとか書くとなおいい。
最近のプロジェクトで導入してみてること

15. Callbackクラス

16. Parameterクラス
Validationや変換等を行ってからActiveRecordや
Formクラスに渡したりするとそれらのクラスの役割
を減らせる。

17. とりあえず最近やってるのはこのくらいです。
ご清聴ありがとうございました