いまさらながらMVC

最近、ちょっと悩んだり考えたりしてたこと。 いまさらながら "MVC" について。 MVCはModel - View - Controllerのアレです。

何を悩んでいたかというと、コンセプトとMVCの関係性をどのように一致させようか？ということ。Web一般での話でも、MVCの話でもないので、たぶん、妙なこと書きます。

MVCっていうけど、実際はそう綺麗に分離しないよな〜ってのが発端。 例えば、Modelって…永続化する/しないでわかれるし、ViewはJSPってイメージだけど、JSPって結局Servletだし、JSPを使わずシンプルにしたい場合ってどうしたらいいんだろ？とか、そんな悩み。

ログインページへ飛ばすのは誰の役割？

もっと悩んでいたのがログインの処理について。ログイン前に日記を書くページに移行とした場合、どこでログインページへ飛ばすか？

Controllerでのバリデーション時にログインチェックを行い、ログインしてなかったらログインページへ。 これって比較的普通な気がするけど、ログインしないと使えないサービスって日記だけじゃないよね？ってことは、バリデーションとは違うところで処理すべきなのかも？ だいたい、ログインだけじゃなく、事前に処理しておきたいこと、事前に確認しておきたいことってあるよね？と思った。

処理によってはチェインさせて色々としたい気もする…とあーでもないこーでもないと色々と考えていてたどり着いたひとつの解が "Controllerをノードとして扱う" こと。 ノードとして扱うことによって、ControllerからControllerへチェインさせればいいのでは？ さっきの日記の件も、LoginController → DiaryControllerとすることにより、解決するのでは？と思った。 …けど、そうでもない気もしている。

ログインって抽象的

そうでもないと思ったのは "ログイン" という行為自体が抽象的であるため。ログインって具体的にはなに？Twitterアカウントがあればいいの？Googleアカウントがあればいいの？それとも、サイト専用のアカウントがあればいいの？TwitterでもGoogleでも、認証できたらいいの？ いきなり「ログインして！」というよりは、DiaryControllerが日記を書くためのアカウントは何かを判断した上でログインページに飛ばしてあげないとわからないんじゃない？ ということは、さっき書いたLoginController → DiaryControllerという遷移ではないということ。

まとまってないけど、まとめに入る

その他にも、DiaryControllerの事前条件を定義しておくってことも考えたけど、複雑にはしたくないし、エラー時のハンドリングを統一的に扱うのは難しそうだし…と色々と悩んでる。 事前条件を定義するというのは、DbCのもうちょっと軽い感じをイメージするとだいたいあってるかも？

無難にController+バリデータでいいかなぁ〜と思いつつも、ノードとして扱うというのも悪くないんじゃないかな？と思っていたりで、未だに結果は出ず。