どーもへっぽこです。
コントローラーって便利ですよね、ルーティングしてアクション呼び出すだけでその中の処理を走らせることができる。
ついつい便利で・・
def A
a = 3
b = 2
c = a + b
return c
end
def B
a = 4
b = 2
c = a + b
return c
end
def C
a = 7
b = 6
c = a + b
return c
end
def D
a = 1
b = 9
c = a + b
return c
end
def E
a = 6
b = 2
c = a + b
return c
end
...
たくさんコードを書いてしまう。。
しかし、こんなコントローラーのことをなんと呼ぶか知ってますか？
ファットコントローラーです！
たくさんのコードで肥やせてしまったコントローラーのことを指すんですね。
さてクイズです、ファットコントローラーは悪いでしょうかそうでないでしょうか？
答えは・・
です！
え、なんで。。
そう思った方！コントローラーの役割を考えてみましょう。
図で表すとこちらです。
出典：エンジニアファースト
見てわかる通り、コントローラーはブラウザーからリクエスト(身近なものでいくとURLでアクセスする)を受け取って、モデルでデータもらって、ビューにそれを渡して、ブラウザにレスポンスを返すのが役割ですね。
つまりコントローラーは・・・
リクエストを受け取って返すだけのために存在しているのです！！！
図でわかる通り、データのやりとりはモデルがしています。
お兄さん、こんなコードをコントローラーで書いたことありませんか？
def index
user = User.all
return user
end
でも図ではこうなってるでしょ？
でも↓のコードは
def index
user = User.all
return user
end
実際コントローラーがモデルの役割を担ってしまってる。
だって、User.allでデータベースにアクセスしてデータ取ってきてるじゃん。
さて寄り道も終わり。
つまりなんでファットコントローラーになってしまうかというと
『本来モデルに書かないといけないところをコントローラーに書いている』
これに尽きます。
じゃあどうすればいいの？
答えは超簡単、モデルに書けばいいだけですね。
以下のようにしてコントローラーからモデルに書いた処理を呼び出せます。
#コントローラー
def index
user = User.get_user
return user
end
#モデル
def self.get_user
user = User.all
return user
end
このコードはさっき出てきた↓のコードと同義です。
def index
user = User.all
return user
end
簡単に説明すると、モデルで def self.○○ で定義しておくとコントローラーで モデル名.○○という形でモデル内で定義したメソッドを呼び出せます。
selfの部分がモデル名にあたるので、Userというモデル名だったらUser.○○、Projectというモデル名だったらProject.○○という形になりますね。
○○の部分はメソッド名、今回はget_userというメソッド名だったので、User.get_userで
user = User.all
return user
↑の処理を呼び出せましたね。
賢いお兄さんならわかったかな？
はいそうです、コントローラーの中身はほとんど書く必要がありません。
ほとんど
def index
#モデルの処理を呼び出す
return 〇〇
end
という形で終わらせることができます。
これを守っていればファットコントローラーになりようがありませんね。
ちょっと発展
モデルに処理を寄せる時、なんでもかんでも処理をまとめることは危険です。
重要なのは
共通化を意識することです。
例えばこんなコードがコントローラーに書かれていたとします。
def projects_data
rewards = Reward.all #ドロップダウンで使用するデータ
locations = Location.all #ドロップダウンで使用するデータ
stations = Station.all #ドロップダウンで使用するデータ
terms = Term.all #ドロップダウンで使用するデータ
skills = Skill.all #トランスファーリストで使用するデータ
os = OperatingSystem.all #トランスファーリストで使用するデータ
db = Database.all #トランスファーリストで使用するデータ
position = Position.all #トランスファーリストで使用するデータ
characteristic = Characteristic.all #トランスファーリストで使用するデータ
tool = Tool.all #トランスファーリストで使用するデータ
end
ドロップダウンは↓で
トランスファーリストは↓
です。
つまり、コメントが書かれたデータはそこでしか使われないという意味です。
このコードをモデルに以下のようにまとめたとします。
def self.get_projects_data
rewards = Reward.all
locations = Location.all
stations = Station.all
terms = Term.all
skills = Skill.all
os = OperatingSystem.all
db = Database.all
position = Position.all
characteristic = Characteristic.all
tool = Tool.all
return rewards,locations,stations,terms,skills,os,db,position,characteristic,tool
end
見ての通り、これだとprojects_dataのアクションでしか呼び出せない汎用性のないメソッドとなってしまいます。
そこでモデルを以下のように変更します。
def self.drop_down
rewards = Reward.all
locations = Location.all
stations = Station.all
terms = Term.all
return rewards, locations, stations, terms
end
def self.transferlist
skills = Skill.all
os = OperatingSystem.all
db = Database.all
position = Position.all
characteristic = Characteristic.all
tool = Tool.all
return [
skills,
os,
db,
position,
characteristic,
tool
]
end
これであればprojects_data以外のアクションでも、ドロップダウンとトランスファーリストを使いたいアクションで個別に呼び出すことができますね。
とても汎用的です。
つまり、処理はモデルに寄せつつその処理は細かく分散していった方が汎用的になりやすいということです。
なので、モデルに処理を寄せる時は共通化する意識を持ちましょう！
以上、へっぽこでした。