Railsライクなフレームワークでのビジネスロジックの扱いについて

Question

お世話になります。

最近CakePHPを業務で使うようになって２・３案件(それぞれ別会社)に携わり実装を見てきたのですが、
全てにおいてコントローラーがやたら長かった印象があります。

というのもStrutsとかSpringとかを触っていた頃は、
「コントローラーはデータの受け渡しや画面遷移だけしてビジネスロジックやDBのデータ操作はモデルに書く」
という風に徹底されていたのでどんなに長くても百行・二百行超える程度でしたが、
直近の案件ですとモデルではDBに対するデータ操作だけをして、
ビジネスロジックまでコントローラーで書いているため千行を超えるコントローラーとかザラです。

流石にこの実装方法はアンチパターンだとは思うのですが、
(CakePHPのドキュメントにもビジネスロジックはモデルで書くって書いてありますし)
CakePHPに代表されるRailsライクなフレームワークがActiveRecordをそのままModelクラスとしているために、
ModelクラスとDBのテーブル(レコード)との紐付きが強くなって複数テーブルのデータを使うロジックや、
そもそもDBへのアクセスを必要としないロジックをモデルに書きづらくなっているのが背景にあるのではないかと思います。

実際のところRailsライクのフレームワークでは、
そういった特定のDBデータに依存しないビジネスロジックはどのように実装するべきなのでしょうか？？

Answer 1

一般的にMVCではコントローラーが大きくなりやすいので、なるべくモデルにビジネスロジックを書くいわゆる「Skinny Controller, Fat Model」となるように実装をするのが理想的といわれています。
ただ、Modelに何でもかんでも詰め込みすぎて肥大化するのも問題(ModelもSkinnyの方かいい)なのでは？と言う意見もあって、ある程度バランスが大事かなと個人的には思います。

DBへのアクセスを必要としないロジックをモデルに書きづらくなっているのが背景にあるのではないか

Railsの場合ですが、DBへのアクセスを必要としないロジック(お問い合わせフォーム)をモデルに書くには ActiveModelを使うとModelと同じように扱うことができます。

class ContactForm
  include ActiveModel::Model
  
end

自分の場合(Rails)ですが、表示系のロジックはHelperメソッドに書いたり、共通ロジックはapp/libフォルダー内に作ったり、Model内で出来る限りscope, default_scopeを使用したり、なるべくコントローラ内にロジックを書かないようにしています。

ちなみにRails4 からはapp/models/concerns、 app/controllers/concerns と言うディレクトリが用意され
複数モデルで共通するコードはモジュールに置くのが推奨されたようです。

Comments

[kinme]

ご回答ありがとうございます。

なるほど、「ModelもSkinnyの方がいい」という考え方もあるんですね。
これについては認識不足でした。
app/controllers/concernsやCakePHPのComponentのような共通の処理の置き場がコントローラー側にあるのはそういった考え方からなのでしょうか。
勉強になりました。ありがとうございます。