WEBアプリケーションでMVCを選択する場面

プロダクトを作る時の技術選定は悩みますよね。
それはWEBアプリも例外ではありません。

昨今のWEBサービスはとてもリッチです。
ブラウザでできることがここ数年で一気に増えました。

ブラウザ上でWEBページを遷移することなく、
入力によって瞬時にコンテンツを切り替えたりすることも
ごく当たり前に見ます。

そんなモダンなサービスを作ろうとすると「API」と
「javascriptフレームワーク（もしくはライブラリ）」を
使用したコンテンツになるでしょう。

そうなると、WEBサーバーで利用するMVC（Model-View-Controller）は
もう古いと感じる方もいらっしゃいます。

しかし、今でもMVCを採用する場面はあると考えています。
それは、「Webアプリを初めて作る」ときです。

javascriptが使いづらかった時代にMVCは活躍していた

MVCは2000年代には活躍していました。

その当時のjavascript事情は良い状況ではありませんでした。

2000年代はブラウザ間の差異がかなりあり、
すべてのブラウザで実行できるjavascriptのコードにすることは
とても労力が必要なことでした。

2010年代に入ってからもブラウザのシェア争いは熾烈でしたし、
CPUも今よりも性能はかなり悪かったです。

そして昨今、ブラウザによる差異とCPU性能が向上し、
API＋javascriptで作るリッチなコンテンツをつくる土壌が整いました。

つまり何が言いたいかというと、

API＋javascriptの組み合わせがでる前は、
長らくMVCでWEBアプリを作るということは
ごく普通のことだったということです。

javascriptを活躍させるには難しい状況は今でもあります。

少しネガティブな結論になりますけれども、
「Webアプリを作る経験に乏しい」こそ、MVCを採用する場面ではないでしょうか。

API＋javascriptフレームワークでWEBアプリを最初に作ろうとすると
情報量の多さから難易度が高めです。

Webアプリをつく経験自体がないのであれば、ブラウザ側の

を学習しつつ、サーバー側の言語（java, ruby, php, etc.）
をコーディングしていくことになるので、単純に学習量が多いのです。

WEBアプリを作る経験が少ないのであれば、機能があるサーバー側に注力したほうが良いです。

というのも、見た目だけ良くてもバグだらけのプロダクトでは
公開までいかない可能性があります。

しかし、機能に重点をおけば、見た目や動きは貧相でも公開はできます。

また、WEBアプリをMVCに作ってしまえば後からAPIに変えることも可能です。

見た目がよく使いやすいコンテンツを作りこむのは、そこからでも遅くはないと思います。

MVCは一度作ってからjavascriptフレームワーク＋APIに移行していくのは
難しいことではありません。

さらに移行を簡単にするためのコツがあります。

それはMVC以外にDBとの間に一層挟むことです。
名前は何でも良いのですが、ここではその層をServiceと呼びましょう。

目的はControllerの役割を薄くすることです。
具体的に言うとViewを表示するためだけ機能をメインにします。

エラーが無ければ通常のView
エラーが発生したならエラー用のViewを表示させます。

それ以外の「値をもとにDBにクエリ発行し・・・」のような機能はControllerに置かないのがポイントです。

そうすることでControllerとViewの部分をAPIとjavascriptフレームワークに
置き換えるだけで、労力が少なく済みます。

ControllerをAPIへの変更することは、
ModelをViewに渡す機能を、Modelをjsonやxmlにする機能に変えるだけになるでしょう。

あとはjavascriptフレームワークを使って、
リッチなコンテンツを作ることに集中するという算段になります。

全ページ一気に変更ではなくURL単位やController単位で変更ができるため、
変更リスクを小さくできるのもお勧めのポイントです。

以上の内容をまとめますと

WEBアプリをつくれるほとんどの開発言語ではMVCが使えるはずです。

最新の技術で作るのも挑戦という意味では悪くないですけども、
難しいと考えたならばMVCを採用することも検討してみてはいかがでしょうか。