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