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.

MvcのFatモデルに立ち向かう

3,010 views

Published on

UniStudy#2 発表資料です。

Published in: Engineering
  • If you want to download or read this book, copy link or url below in the New tab ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { https://urlzs.com/UABbn } .........................................................................................................................
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

MvcのFatモデルに立ち向かう

  1. 1. MVC FatModelに立ち向かう - 挑戦 - (Railsベース) Unicast Inc. Web Engineer 疋田 駿 UniStudy#2 @ シェアハウスコクリエ
  2. 2. 話す人 株式会社ユニキャスト セールスエンジニア ▷ 2015年入社の新卒文系Webエンジニア(23歳) ▷ Ruby, Ruby on Rails, PHP, AngularJS, WordPress ▷ Microservicesなサービス作り希望 http://qiita.com/shunhikita https://twitter.com/shunhikita
  3. 3. 1. そもそもMVCとは? Model, View, Controller ?
  4. 4. “MVCは、ユーザインタフェースを持つアプリケーションを 実装するためのデザインパターンである。 内部データをユーザが直接参照・編集する 情報から分離する。 参照: Model View Controller - Wikipedia https://ja.wikipedia.org/wiki/Model_View_Controller
  5. 5. ModelView Controller USER ユーザのリクエストを受け取る Modelにメッセージを送り Modelからデータを受け取る Viewにデータやメッセージを送り 生成されたHTMLやJSON等を受け取る MVCはいろいろな意見があるので あまり触れたくない。。。PushとかPullとか Viewで生成したものを Userに返す。 そのアプリケーションに関わる ビジネスロジックを扱う ユーザからのリクエストを扱う ユーザとの接点となるビューを扱う
  6. 6. 2. SkinnyController&FatModel 薄いコントローラ、厚いモデル
  7. 7. Controllerは便利です。 ControllerはViewともModelともUserとも全てとつな がっています。 ModelView Controller
  8. 8. そしてコントローラが肥大化します。 コントローラにビジネスロジック!?
  9. 9. だから コントローラは薄く (SkinnyController)しろ! って言われてきましたね。
  10. 10. そして Fatモデル です。 Modelは ビジネスロジック全般の責任を 持ちます。 役割が多いんです。 (ここからはRails系の話です。)
  11. 11. ActiveRecord ▷ Railsでは基本的にModelを作成する ActiveRecord::Base を継承して クラスが作成されます。 ▷ ActiveRecordはActiveRecordパターンを実現するためのgemです。 ▷ ActiveRecordはロジックとDBへの永続化をまとめてカプセル化し、 データにドメインロジックを追加します。 ▷ CRUD+αくらいならこのクラスにドメインロジックを書いていくことで上手く行 きますが、中規模以上だと、ロジックが多くなり非常に辛くなります。 => Fat Model!! でもね、 Model = ActiveRecord    じゃないよ。
  12. 12. 解決策 ▷ ActiveRecordから責任を分離していくこと。 ▷ それぞれの役割を分離するための仕組みがRailsには用意されています。 (流石Rails!!流石Ruby!!) ダメ!絶対! ▷ 肥大化したActiveRecordクラスからメソッドをモジュールに移動して ミックスインするの。 ▷ 結局モデルにミックスインされるんだから変わらない。 ▷ 見た感じ良くてなっても無理やり詰め仕込んだ感。。。結局一つのモデル にたくさんの責務を持たせることに変わりはない。
  13. 13. 3. Fatモデルに立ち向かう ActiveRecordから仕事を奪え! 手探りで挑戦中です。みなさんのご意見下さい。
  14. 14. モデル分割 callbackクラス 汎用的なcallback対応メソッドの再利用 適切な名前付け validatorクラス 汎用的なValidationの再利用 decoratorクラス それぞれのViewに適した表現はActiveRecordクラスで加工するので なくdecoratorクラスで加工 formクラス 一つのフォームで複数のモデルを操作するなど、それ専用のクラスを 作ると表現方法が広がり無駄なビジネスロジックの記述が減る。 Parameterクラス フォームから送られてきたデータを modelやformオブジェクトに適した 形に変換したりバリデーションをかけたりするラッパのような存在。 Queryクラス スコープやクラスメソッド等が乱雑に定義された、複雑な SQLクエリや 汎用性のあるクエリは Queryクラスで行うと便利。 Searchクラス 検索は条件が同じ場合が多かったりするので、 Searchクラスを作ると 便利。クラスマクロとか書くとなおいい。 最近のプロジェクトで導入してみてること
  15. 15. Callbackクラス
  16. 16. Parameterクラス Validationや変換等を行ってからActiveRecordや Formクラスに渡したりするとそれらのクラスの役割 を減らせる。
  17. 17. とりあえず最近やってるのはこのくらいです。 ご清聴ありがとうございました

×