Controllerの概念
モデルやビューは実体が複数あることは明確だ。
一方controllerは、実体がなく、モデルとビューの橋渡し役だ。区切り方は作り手に委ねられている。
controller自体が1つの実体とするなら、
人間の可読性を無視するなら、1つのファイルにまとめてもいいのだ。（パスだって変えようと思えば/usersや/messagesなど変えられるのでエンドユーザーにはユーザーフレンドリーが担保される）
逆説的に述べると、可読性のためにも分割していると言っていい。（開発者のためのForDeveloper設計）
今までの色々な意見（分け方）
a. controllerはあくまで人間の認識に合わせる。ユーザーやチームが想定しやすいところに置くのが一番。(ForDeveloper, ForHuman設計)
- URLからcontrollerが想定できるようにしたい(ForDeveloper設計)
- でなければ、/rankingsなのにusers_controllerは特定がしんどい（チームの共通認識だいじ。）
- しかし、コンテキスト(意味合い)に重きをおくと、人によって想定するものが違う可能性は多いにあり、こわい。
b. 1つのモデルに対する一連の操作をまとめたものがcontrollerだ。(モデル依存)
- メインとして出力するモデルがxxxならxxx_controllerという考え。
- では、companiesとusers両者同じ画面に同じ重要度でだす場合は？
- カテゴリ一覧は/categories。だが、カテゴリに入っているユーザー一覧はusers_constrollerから出すべき
- なぜならそのユーザー一覧は、Viewにとっては同じusersを出力してるに過ぎないのだから。
- ソートとフィルターはクエリ（?filter=xxxx)を使う
c. 可読性向上のために分割する。(ForDeveloper設計)
- ファットになったり混沌としてきたら、aのように適材適所に分ける。
controllerの分け方。あなたはどうする？
以下はあなたの想像力を膨らませるための例材。
model
- messages
- users
- categories
- inquiries(問合せ一覧)
view
- メッセージ一覧
- ユーザー一覧
- メッセージをくれたユーザー一覧
- ユーザーのランキングを表示
- カテゴリ一覧
- カテゴリ一覧をみながら特定のユーザーのメッセージ一覧を見て、メッセージが気に入ったらそのユーザーをカテゴリに追加する画面
- 問合せ一覧
- カテゴリ一覧をみながら特定のユーザーのメッセージ一覧を見て、メッセージが気に入ったらそのユーザーをカテゴリに追加する画面。ついでに問合せ一覧も出力しちゃう♡