クライアントサーバの3階層システムの基本
3階層システムとは
別名 : 3層システム / 3層クライアントサーバシステム / 3階層アーキテクチャ / 3-tier system
クライアントサーバシステムを
- プレゼンテーション層(ユーザインターフェース部分)
- アプリケーション層(ビジネスロジック部分)
- データ・アクセス層(データベース部分)
の3層に分割して構築したシステム。
クライアントおよびサーバの処理を複数の階層に分離して配置することで、ある階層へ変更を加える必要が生じた際にも柔軟に対応できるようなっている。
3階層システムでは、クライアント側にはユーザインターフェース部分のみを残し、あとはサーバ側に実装する。クライアントはユーザからの操作を受け付け、アプリケーション層からの処理結果を表示することのみを行う。
アプリケーション部分をクライアントから分離してサーバに実装することにより、ビジネスロジックが変更された場合でもサーバ側のアプリケーションを変更するだけでよく、変更がシステム全体に及ぶことは無い。また、大量のデータを扱うシステムでは、ネットワークを通じてクライアントとサーバの間で大量のデータのやり取りをする必要が無くなる。
各層の役割
プレゼンテーション層(ユーザインターフェース層 / UI層)
- ユーザーに情報を表示したり、ユーザーからの入力を受け付けたりする機能を担当するレイヤ
- 細かな変更や拡張が発生しやすい
- 使い勝手を向上させるためのインターフェイスの改善
- 新デバイス対応など(PDAや携帯電話対応など)
などなど
プログラムは、ユーザー・インターフェイスの実装なので、ほかの層に比較すれば、実装やテストにかかるコストはそれほど大きくない
アプリケーション層(ビジネス・ロジック層 / ファンクション層)
- アプリケーションの実際の情報処理を担当するレイヤ
- 業務フローや各種データ処理など、ビジネスで必要な情報処理をソフトウェアとして実装するレイヤ
- 本質的な部分は比較的長期にわたって変わりにくい
- ビジネスの処理そのものをプログラムとして表現したもの
- ユーザー認証やトランザクション処理など、プログラム実装やテストには多大な工数が必要になることが多い
データ層
- データベース・システムへのアクセス・保存機能を組み込むレイヤ
- データベースの構造を変更することはそれほどない
- 本質的なデータ構造自体は何十年も変わらず使い続けられるというケースも少なくない
- ただ・・・
- あらかじめ業務分析をきちんと実施してデータ構造を決定しておく必要はある
- アクセス効率や可用性、セキュリティ性能向上など、運用面からデータベース構造の見直しが発生することはある
- 利用するデータベース・システム(例えばSQL Serverか、Oracleかなど)によって内容が大きく影響を受ける
- 逆に考えると・・・
- データ層を独立させることで、データベース・システムの違いから、ビジネス・ロジック層を分離できるというメリットがある
- 逆に考えると・・・
3層構造はMVCと一緒のものでしょうか?
層構造をお勉強していて思った、「MVCモデルと似てない?」「一緒?」
- プレゼンテーション層 - View
- アプリケーション層 - Controll
- データ層 - Model
な感じ?
「3層構造」「MVC」なんかでググるとすぐにわかります。それは間違いです。
違い : 3層構造は直線でつながる
MVCは三角でつながる -> プレゼンテーション層とデータ層はつながらないが、ViewとModelはつながる
違い : 表しているものが違う
- 3層構造 : データベース〜ユーザーの間の情報経路
- MVC : ユーザインタフェースにおける画面上のコンポーネントの管理方法
という訳で違う、その違うものを対応させようとしたのがおかしいという結果です。
思い出の一枚