woshidan's loose leaf

ぼんやり勉強しています。

RailsのModelとControllerにどういうメソッドを書くのか

RailsのModelとControllerにどういうメソッドを書くのか分からなくてグルグルしていた。 好みやプロジェクトの雰囲気によると思うのだけれど、自分の実感として、

  • 使い回さない判定
  • 使い回さない検索

はControllerに書いてあることが多い気がする*1

自分としては、 Modelの責務はデータベースとの接続を取り扱うみたいに思い込んでいた部分があって、 データベースに入ってる値を使う処理はModelに置くのが好きだ。 上記は、両方Modelに置く事が多い。

けれど、Controllerはクライアントからの入力を受け取って、 Modelのメソッドを呼び出したり、renderするViewを指定したりするのが責務*2みたいなので、 使い回さない検索、検索用の値がクライアントからの入力値だけの場合は特に、 Controllerに置いたほうがいいのだろう、と思う。

そういえば、そもそも

ビジネスロジックは以下の部分からなる[1]:
ビジネスルール - ビジネスに関する方針を表現したもの(経路、位置、輸送、価格、製品など)
ワークフロー - ある関係者(人間またはソフトウェア)から他の関係者へと文書やデータを渡す仕事の順序

ビジネスロジック - Wikipedia より

という話や、

Model
そのアプリケーションが扱う領域のデータと手続き(ビジネスロジック - ショッピングの合計額や送料を計算するなど)を表現する要素である。また、データの変更をviewに通知するのもmodelの責任である(modelの変更を通知するのにObserver パターンが用いられることもある)。 多くのアプリケーションではデータの格納に永続的な記憶の仕組み(データベースなど)が使われている。MVCの概念では、データの(UI以外の)入出力は取り扱わないので、データアクセスも本来MVCの概念の範疇を超えるものではあるが、あえて言えばmodelの中に隠蔽されると考えられる。

Model View Controller - Wikipedia より。

という話を読むと、データアクセスは本来Modelの仕事じゃなく、実質実装上便利だからそうなってることが多いみたいな部分もあるのかもしれない。

じゃあ自分は、最終的にどうしていくのか、というと、上の話は前々関係なくて、

  • フレームワークごとにお作法が異なるのでフレームワークやプロジェクトの空気を読む
  • テストが書きやすい方に実装を寄せる
    • コンピュータの動きをコンピュータが追跡できないような不思議なメソッドは書かない
  • コントローラとモデルでメソッドが被っているのを発見次第消す
    • どちらに責務があるかが曖昧になっているのはたしかに好みの問題の部分がある
    • だが、その結果同じ値が複数箇所で定義されていて、どれを使っていいか分からない
      • 下手したら、実装した人間の想定とユーザが見ている値が違うのは実利的な問題
    • mergeの前にgrepする

そう、mergeする前に関数名、関数の中で呼び出しているメソッド名でgrepするようにしよう。 grepする気が起きない程度に巨大なメソッドメソッドが影響を持つ、grepすべき範囲が分からない程度に汎用的すぎるメソッドは、 まだ私には扱えないので書かないようにしようと思う。

*1:それがMVCとして正しいかは知らない

*2:この表現はDispatcherと混じっている気がする