■Fat Controllerを作ってしまいがちな訳

http://ugaya40.net/architecture/dis_mov.html

Fat Controllerはダメというのは昔から言われている話で、自分も昔読んだときになるほどと思ったので「なるべくControllerを薄く」を頭に置いているのだけど、どうもうまくいった感じがしなくて挫折感があった。その理由だけど、自分の経験から言うと、「Viewに変数を渡すのがめんどくさい」「途中で処理を中断するのがめんどくさい」の2点だと思う。

「Viewに変数を渡すのがめんどくさい」

たとえばRailsだとController内でインスタンス変数に代入することによってViewに変数を渡すことができる。処理をModelに移すとModelからControllerに変数を返して、ControllerでViewに変数を渡すという二段階が必要になるのでこれがめんどくさい。（正確には、ControllerからModelの状態を取れるように作るのが正しいのだろうけど、Viewで必要となるあらゆる状況を想定してModelの状態を取れるようにするのはなかなか大変。それだったらControllerで処理しちゃって……としてしまいがち）

「途中で処理を中断するのがめんどくさい」

たとえばRailsの場合、Controllerからreturnすればその時点で処理が中断されるし、レスポンスもそこでrenderしておけばよい。しかし処理をControllerに移した場合、Model内で起こったことに応じて適切なレスポンスを返すコードをControllerに書かなくてはいけないが、これがめんどくさいように思う。Modelから直接レスポンスやViewを指定したくなってしまう。（もちろんそれはできないし、Modelの分離の観点からするべきでもない）

O/RマッパーのModelに一切処理を追加しないなんてことはなくて、Modelで処理できることは極力Modelに移しているつもりではいるのだが、どうしてもすっきり書けた感じがしない。

もちろんわかっている人ならこんなところでひっかからず、自分がわかってないだけの可能性が高いのだが、自分が上のような理由で挫折してしまったのは事実なので、何とかしたいとは思っている。

自分としては、理屈はわかるけど実際のコードはどうなんだという感じなので、「これは手本にすべきMVCのウェブアプリケーションだ」というのがあれば読んでぜひ参考にしたいのだけど、何かないものだろうか。

Permalink | 記事への反応(2) | 12:34

ツイートシェア