Rails設計パターン
Rails設計パターン
Railsの設計パターンについて、殴り描きします
MVCパターン
RailsTutorialから入った自分には一番馴染みの設計パターン
ルーティング(Routes)→コントローラー(Controller)→モデル(Model)→ビュー(View)の順番で処理がなされる
画像参考:【Rails】 MVCフレームワークを初心者向けに丁寧に解説! | Pikawaka
コントローラー設計の時に考えるべきポイント
1. 薄いコントローラーを意識する
コントローラの役割はユーザーのリクエストが不正でないかのチェックとレスポンスコードを返すです。 コントローラーにロジックをゴリゴリ入れるのはNG。薄いコントローラーである程よい。
例)コントローラーにロジックを入れすぎなサンプル
def index @published_posts = Post.where('published_at <= ?', Time.now) @unpublished_posts = Post.where('published_at IS NULL OR published_at > ?', Time.now) end
次のように変更した方がベターです
def index @published_posts = Post.published @unpublished_posts = Post.unpublished end
モデルにロジックを書き写します
scope :published, ->(timestamp = Time.now) { where('published_at <= ?', timestamp) } scope :unpublished, ->(timestamp = Time.now) { where('published_at IS NULL OR published_at > ?', timestamp) }
2. RESTなコントローラーを意識する
:index, :show, :new, :create, :edit, :update, :destroyといった基本的なaction以外はできる限り利用しない方がベターです。 RestfuleなWEBアプリを意識しましょう
モデル設計の時に考えるべきポイント
1. データベースへの格納方法は、Modelに隠ぺいする
モデルクラスには、データベースを取り扱う(データベースへの格納方法は、Modelに隠ぺいする)という役割。 その役割から逸脱しないようにプログラムを書きましょう。
MVCアンチパターン
MVCにそれぞれ責務が存在します。
レイヤ | MVC |
---|---|
ユーザインタフェース層 | View |
アプリケーション層 | Controller |
ドメイン層 | Model |
ユーザインタフェース層: ユーザに情報を表示し、ユーザの入力を解釈する。
アプリケーション層:ドメイン層のオブジェクトを協調させる。ビジネスに関する知識を持たず、作業を調整するだけ。
ドメイン層: わゆるビジネスロジックを表現する。一番重要な層。
上記のような責務に綺麗に分けてコード書くのがベストなのですが、多くのフレームワークがそのように分離することに強い制約を持っているわけではないのでアンチパターンなコードになってしまうケースがあります。
例)Fat View
- ユーザインタフェース層にアプリケーションやドメイン層のロジックが詰め込まれた状態
- Viewから直接Modelを触っているとn+1問題が頻出する
例)Fat Controller
例)Fat Model
- なんでもかんでもModelに詰め込んでいる状態
- アプリケーション層のロジックまでModelに含まれていることも多い
Railsアプリケーションが巨大化した時の対象方法
プロダクトが肥大化してきて、MVCではコードの管理がキツくなってきた時の対処方法を記載します。
こちらの記事が非常にわかりやすかったです。
中/大規模開発のためのRails設計パターン - Qiita
お手軽な第一歩としてはserviceレイヤーを導入するのが、一番簡単な対象方法
参考
肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳)|TechRacho by BPS株式会社
Railsのアーキテクチャについて考えるための読み物まとめ - Qiita
実務で学んだRailsの設計・リファクタリング | wawoon