Skip to main content

One post tagged with "MVC"

View All Tags

· 5 min read

最近、ちょっと悩んだり考えたりしてたこと。 いまさらながら "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+バリデータでいいかなぁ〜と思いつつも、ノードとして扱うというのも悪くないんじゃないかな?と思っていたりで、未だに結果は出ず。