2014年10月12日日曜日

WebアプリにおけるMVC

初心者にとっての難関の一つがMVCの考え方だと思います。
作るものやフレームワークによって微妙に定義が異なりますが、Webアプリにおける基本と思えるMVCを解説いたします。

上記の図は、命令の流れです。
各セクションを解説いたします。

・Model
アプリケーション本体と言える部分です。 広い意味でのCore部分となります。
サービスの処理内容(ビジネスロジック)を書くところですね。すなわちデータ操作部分であり、データを格納している部分でもあります。

・View
UIを構築する所です。すなわちhtmlを構築するテンプレート部分ですね。

・Controller
ブラウザから送られてきた内容や、処理結果によって処理を分岐させる所です。
図には描かれていませんが、Modelからの結果をControllerが受け取り、その内容によってViewへ命令を出します。


ViewがブラウザにUI表示命令を出し、ブラウザからControllerへ操作実行命令を出し、Controllerが命令内容に従いModelやViewに命令をだし、ControllerがModelから受け取った結果によってもViewに命令をだしとなります。


MVCを他にたとえて見ますと
Model→街
View→地図
Controller→標識
こんな関係に近いかもしれませんね。


しかしMVCだけでは全ての処理を含める事はできないので、他にHelperやUtilityといった分類も登場します。

・Helper
MVCに振り分けられない処理を書きます。たとえばViewのためにデータを整形する場合ですね。
Mに含めてもよさそうですが、Mは汎用的な処理内容にとどめないとどんどん肥大化していってしまいます。
特定ページのみの処理などはHelperに書くとすっきります。 後で探すのが楽になるというのは非常に重要です。


・Utility

1つのメソッドで完結しアプリからは独立した汎用的なロジックを置く所です。どこにも依存しないので通常はstaticとなります。
Helperと違うのは、完全に独立した処理で、アプリのどこからでも使えるどころか、他のアプリでも未改造で使いまわせる所にあります。
たとえば、日にちの差を求めるメソッドなどですね。
スニペット集みたいなもので、昔は汎用ライブラリと呼ばれていた部分です。


以上の分類方法を身につけると、拡張性が高く見やすいソースになりやすいと思います。
手抜きしてごちゃまぜにすると、後で修正に苦労してさらにバグだらけになりとカオスになっていきます。
継続してアップデートしていくWebアプリで一番重要なポイントは、後で修正しやすいかどうかとなります。一言で言うと拡張性です。