Webアプリケーションを作る際によく使われるのが、MVCモデルです。今回は、このMVCモデルに焦点を当ててみます。
MVCとは
- Model
- View
- Controller
の頭文字を取ったモデルで、主にクライアント・サーバーシステムを構築する際に使われるデザインパターンです。
それぞれの層を明確化することにより、明瞭かつ改修しやすいプログラムを作ることが目的です。
プログラム設計の上では、役割を持たせることはとても大切ですが、MVCモデルというひとつの共通認識により役割の伝達をしやすくする、というのは合理的ですね。
View
専ら、画面への表示を担当する層です。コード上ではjavaのJSPや、ASP.NET MVCにおけるRazorなどのテンプレートエンジン、Ajax通信を主とするHTML+JavascriptなどがViewにあたります。
誤解を恐れずに言うと、ユーザーが見える範囲全てがViewと言っても差し支えありません。
過去に、ここにビジネスロジックや、果てはデータベースアクセスまで書いているプログラムを見かけましたが、重罪です。絶対にやめておきましょう。
Controller
Controllerは、ViewとModelの橋渡し役です。ここにビジネスロジックを書くのも避けるべきです。
よく、Controllerの定義を誤って解釈している人がいますが、MVCモデルは、「三層クライアントサーバシステム」の「ファンクション層」ではありません。混同しないように気をつけてください。
Viewから受け取ったフォームの値や、JSONなどをModelに渡したり、逆にModelから貰った値をViewに渡したりしたりするのが役割です。MVCの中では、最もシンプルなコーディングになるはずです。
Model
それ以外の全てです。
ざっくりすぎますが、データベースアクセスからビジネスロジックまでの全ての処理を担います。
しかし、いくらなんでも、全てmodelパッケージに突っ込んでしまうと、複雑なシステムは非常に読みづらくなってしまいます。
そのため、modelの中でも、いくつかの役割を分けてシステムを構築する必要が出てきました。いくつか紹介します。
DAO
Data Access Objectの略で、専らデータベースアクセス処理を担うのがこのクラスです。煩雑になるビジネスロジックからこの処理を排除する事で、よりシンプルになりました。
もし、データベースを変更（例えばカラム名の変更）することになっても、DAOさえ変更すればよいので、影響範囲の調査も容易です。
Service
ビジネスロジックすら分けてしまおうと考えたのがサービスクラスです。オブジェクト指向といえば、privateフィールドに対して値を変更するのが基本だったわけですが、それらのメソッドを全て外に出し、フィールドを後述するDTOに纏めてしまえば、より疎結合なシステムを設計する事ができると考えました。
このように、ビジネスロジックを全てサービスクラスに格納したシステムもありますが、そうでないものも多数あります。プロジェクトによって最も認識に差異があるのがサービスクラスかもしれません。
DTO
以下の記事で詳しく説明していますので、概要に留めます。
DAOやサービスクラスの登場により、オブジェクトにメソッドが必要なくなりました。それならシンプルにしてしまえばよい、と登場した、ただの箱です。
最後に
一口にMVCモデルと言っても、時代の変遷やフレームワーク、プロジェクトの方針により大きく変わります。ですので、何が正しい、何が間違っている、ということは一概には言えません。
こういった引き出しを増やすことで、システムによって最適な選択肢を選んでいければと考えています。
設計は簡単ではありませんが、適切な判断のために、インプットは欠かさないようにしたいものです。