3層アーキテクチャやMVCモデルの意義
保守性の高いアーキテクチャを考える
https://gyazo.com/05c1318eef3c3c93bacf953b87735304
アプリケーションでは次の処理を行うことになる。
リクエストを受け付ける、解釈する。
データベースに問い合わせるためのSQLクエリを作成する。
クエリ結果を解釈する。
レスポンスを返す。
しかし、これらの処理を1つのプログラムに収めることは望ましくない。なぜか?
一枚岩でやろうとすると、一つの局所的な変更が全体に影響を与えるから。
1. 外部からやってくるリクエスト、外部に返すレスポンスの仕様が変化した場合、リクエストを受け付けたり解釈したりするコードをすべて変更しなければならない。
2. DBMSやデータベースの仕様が変化した場合、SQLクエリを作成したりクエリ結果を解釈したりするコードをすべて変更しなければならない。
3. 変更されたコードが生成するデータを利用するほかの部分も変更しなければならない。
どうすればよい?
外界とやり取りする部分と、データの処理・加工を担当する部分と、データベースとやり取りする部分とを分ければよい。
プレゼンテーション層: 外界とのやり取りを担当
ビジネスロジック層: データの処理・加工を担当
データアクセス層: データベースとのやり取りを担当
https://gyazo.com/4b16ca901aba7f30a29bacc26c7aaa69
GUIをもつアプリケーションのための設計パターンの一つ。 プレゼンテーション層とビジネスロジック層で行うことをより具体的に規定しているアーキテクチャといえる。
https://gyazo.com/70df8bce7b5420354b9bb6c5e984b042
この図はMVCモデルを3層アーキテクチャに落とし込んだり、M-V間やV-C間の通信を原典に載っている図のObserverパターンのような方法とは別の方法で実現したりすることを前提にした図であることに注意。 https://gyazo.com/70801a0e6b228ee0573cbc748ff1c4fe
補足
「プレゼンテーション層とビジネスロジック層で行うことをより具体的に規定しているアーキテクチャといえる」と記したが、MVCモデルが三層アーキテクチャの一部として開発されたわけではないことに注意されたい。
MVCモデルが誕生したのは1980年代であるとされている。
三層アーキテクチャが誕生したのは1990年代であるとされている。
参考にした資料