@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

Fat Model問題

Fat Model問題を説明してみましょう。 ここでいうFat Model問題とはRuby on Raisを使って書かれたWebアプリケーションにおいてモデルクラスが大きくなりすぎる問題のことをいいます。 Ruby on Railsでは、MVC(model-view-controller)というアーキテクチャパターンを採用しています。

第1章 ゼロからデプロイまで - Railsチュートリアル

ブラウザがRailsアプリと通信する際、一般的にWebサーバーにリクエスト(request)を送信し、これはリクエストを処理する役割を担っているRailsのコントローラ(controller)に渡されます。コントローラは(ユーザーなどの)サイトの要素を表しており、データベースとの通信を担当しているRubyのオブジェクトであるモデル(model) と対話します。モデルを呼び出した後、コントローラは、ビューを描画し、完成したWebページをHTMLとしてブラウザに返します。

Ruby on Railsではコントローラーには処理をほとんど書かずに、モデルクラスの呼び出しのみを書くべきだとされています(要出展)。 例えば、DHHが示したBasecamp3というアプリケーションの統計情報では、コントローラーのメソッド辺りの行数(LOC/M)は3行しかありません。

では処理はどこに書くのでしょうか?MVCの残りの登場人物はモデルクラスとビューです。 MVCはPresentation Domain Separation (PDS)原則に則っています。 ビューにはプレゼンテーション(見た目の整える)処理のみを書きそれ以外の処理はモデルに書きます。 つまり、見た目に関わらないほとんどの処理はモデルクラスに書きます。

この方針のまま大きなアプリケーションを実装したらどうなるでしょうか? 大きなモデルクラスが誕生します。 モデルクラスが大きくなると変更が難しくなります(なぜ?)。 これがFat Model問題です。

で、DHHのツイートを見なおしてみましょう。 モデルクラスは2万行近くあって300個以上あります。 が、クラス辺りのメソッド数(M/C)は8しかないしメソッド辺りの行数は3なんですよね・・・どこがFatなのか? ServiceクラスもFormオブジェクトも使わなくともFat Model問題は起きないみたいですよ?どういうことですか?

参考

20220317追記

texta.fmの第7回「Fat Controllers and Models」を公開しました! - てくすた を聞きました。

  • コントローラーの方がテストを書きにくいので、Fat Controller vs Fat ModelならばFat Modelがまし
  • Fat Modelになるのはデータモデリングが出来ていないため。テーブルが少ない。典型的にはテーブルが、リソースのみでイベントエンティティがない。
  • クラスメソッドが多いのは悪いコードの匂い。特にモデルクラスから別のモデルクラスのクラスメソッドを呼んでいるのは良くない。

つづいて 本ブログのポッドキャスト「texta.fm」を始めました! - てくすた の3. Low-Code Developmentも聞きました。 半分寝落ちしてましたが、「URL設計とデータ設計が上手くできればRailsは高速開発できる」みたいな話が面白かったです。