この特集のトップページへ
＞ Chapter 1：クライアント/サーバーアプリケーションの仕組み

見出し 1.1.4　2階層モデルから3階層モデル，そしてN階層モデルへ
　以上の説明から，クライアント/サーバーアプリケーションを構築する場合の問題については理解していただけたものと思う。クライアント/サーバーアプリケーションを構築するときには，データベースに複数のクライアントが同時にアクセスしたときの整合性をどのように解決してゆくのかを考える必要があるのだ。

　では，具体的にどのようにしてクライアント/サーバーアプリケーションを構築すればよいのだろうか。「1.1.2　クライアント/サーバーアプリケーションモデル」でも説明したが，クライアント/サーバーアプリケーションの構築形態は，クライアント側にデータベースの処理部を実装するのか，それともサーバー側に実装するのかに大きく分類される。前者を「2階層アプリケーションモデル」，後者を「3階層アプリケーションモデル」と呼ぶ（Fig.1-9）。

Fig.1-9　2階層アプリケーションモデルと3階層アプリケーションモデル
fig.1-9 fig.1-9

　先にも説明したが，クライアント/サーバーアプリケーションを構築する場合，最近では3階層アプリケーションモデルを採用することが多くなっている。3階層アプリケーションモデルをもう少し模式化して描くと，Fig.1-10のようになる。

Fig.1-10　3階層アプリケーションモデル
fig.1-10

　3階層アプリケーションモデルは，クライアントで動作するアプリケーション（プレゼンテーション層），データベースにアクセスするプログラム（ビジネスロジック層），データサービスを提供するデータベース（データストア層）という3層で構成されている。各層の役割は，次のとおりである。

  1. プレゼンテーション層
    Fig.1-10において一番左側に描かれたプレゼンテーション層は，クライアント側で動作するアプリケーションである。このアプリケーションがユーザーにインタフェースを提供し，データベースに対するさまざまな操作の窓口となる。具体的には，ユーザーに対してデータベースの内容を表示したり，ユーザーの操作に基づいてデータベースの内容を変更するように要求を発したりする機能を提供する。

    　プレゼンテーション層にあるアプリケーションは，直接データベースにアクセスするのではなく，ビジネスロジック層に配置されたプログラムに，その処理を依頼しているにすぎない。

  2. ビジネスロジック層
    Fig.1-10において中央に描かれたビジネスロジック層は，プレゼンテーション層と次で説明するデータストア層とを中継するもので，データベースを操作するためのプログラムが含まれる。このプログラムは，プレゼンテーション層に相当するアプリケーションから呼び出され，指定された操作をデータベースに対して施す。たとえば，プレゼンテーション層のアプリケーションから，「製品Aを10個注文する」という指示が伝えられた場合，ビジネスロジック層に配置されているプログラムがデータベースに接続し，データベースのテーブルに「製品Aを10個注文」という情報を登録する（より細かくいえば，製品Aの在庫を10個減らし，注文書のテーブルに発注情報を書き込む）などの処理を施す。

  3. データストア層
    Fig.1-10において一番右側に描かれているデータストア層には，データベースエンジンなどが含まれる。たとえば，SQL Server，Oracleなどのデータベースは，データストア層に含まれる。

    　データストア層のデータベースは，ビジネスロジック層に含まれるプログラムからアクセスされ，直接プレゼンテーション層のアプリケーションからアクセスされることはない。

　ここで重要なのは，3階層モデルでは，データベースに対する操作はすべてビジネスロジック層に配置されたプログラムを経由して処理され，クライアント上に配置されたプレゼンテーション層のアプリケーションから直接データベースにアクセスされることはない，という点である。このような仕組みによって，次のようなメリットが得られる。

  1. ロジックを集中管理できる
    データベースにアクセスするプログラムは，ビジネスロジック層に配置されたプログラムのみである。すなわち，データベースにアクセスするプログラムを一箇所にまとめることができ，ロジックを集中管理することができる。

  2. データの整合性を保つことができる
    クライアントからの要求はすべてビジネスロジック層を経由する。そのため，データベースに対する排他制御をビジネスロジック層に実装することで，データの整合性を保つことができる。また，適切なセキュリティ機構をビジネスロジック層に実装することで，許可のないクライアントの接続を拒否することもできる。

  3. プレゼンテーション層の構築が容易である
    プレゼンテーション層に相当するアプリケーションの役割は，ユーザーインタフェースを提供することと，ビジネスロジック層に配置されたプログラムを呼び出すことだけである。すなわち，プレゼンテーション層のアプリケーションを構築するにあたっては，データベースの知識は必要ない。

    　また，3階層モデルでは，顧客の要求に応じて複数のユーザーインタフェースを提供することも比較的容易である。たとえば，（Windowsのネイティブな実行形式ファイルとして）スタンドアロンで動作するユーザーインタフェースと，Webページとして動作するユーザーインタフェースの2種類をユーザーに提供することを考えてみよう。2階層アプリケーションモデルでは，スタンドアロンで動作するプログラムとWebページとして動作するプログラムのそれぞれに，データベースに対してアクセスする機能を実装しなければならない。しかし，3階層アプリケーションモデルでは，データベースに対する処理はビジネスロジック層に配置されたプログラムに一任されるため，何種類のユーザーインタフェースを提供しようとも，データベースに対するアクセス部分はビジネスロジック層に1つだけ用意すればよい。

  4. アップデートが容易である
    構築したアプリケーションをアップデートする場合，データベースエンジンを変更するだけであれば，クライアント側のアプリケーションまで変更しなくてもすむことがある。たとえば，最初はデータベースとしてAccessのJetエンジンを使っていたとしよう。しかしその後，SQL Serverに変更したいとする。この場合，データベースの操作方法が異なるため，データベースにアクセスするプログラムには一部変更を加える必要がある。3階層アプリケーションモデルでは，データベースにアクセスする部分はビジネスロジック層に配置されたプログラムであり，クライアント側で直接利用するプレゼンテーション層のアプリケーションではない。よって，ビジネスロジック層に配置されたプログラムだけを修正すればよく，クライアント側のアプリケーションはアップデートする必要がない。

  5. 分散処理ができる
    3階層アプリケーションモデルでは，それぞれの階層をどの場所に置くこともできる。1台のコンピュータのなかにすべての階層を収めてしまうこともできるし，各階層ごとに1台のコンピュータを割り当ててもよい。つまり，論理的な階層を自由に物理的な階層へとマップすることができる。

    　一般的には，プレゼンテーション層を個々のクライアントコンピュータにインストールし，ビジネスロジック層とデータストア層をサーバーにインストールして，互いにネットワーク通信でデータをやり取りすることになる。このときサーバーは，ビジネスロジック層に1台，データストア層に1台の計2台を割り当ててもよいが，1台のサーバーにビジネスロジック層とデータストア層を配置してもかまわない。また，これは別に2台しか割り当てられないということではなく，ビジネスロジック層とデータストア層のそれぞれに複数台のサーバーを割り当てて，さらに分散処理をすることもできる。

　アプリケーションを階層構造で開発する場合，必ず階層を3つに分割しなければならないということではない。より複雑な処理を求められている場合には，ビジネスロジック層をさらに細分化し，4階層，5階層，……と階層を重ねることもある。そのため，3階層アプリケーションモデルは，「N階層アプリケーションモデル（多階層アプリケーションモデル）」と呼ばれることもある。

　3階層アプリケーションモデルには上述のようなメリットがあるものの，全体の開発量は若干増加する。なぜならば，クライアント側のプレゼンテーションプログラムと，データベースを操作するビジネスロジックプログラムの，最低でも2つを開発しなければならないからである。一般的に，データベースを操作するプログラムは処理別に複数に分割するため，ビジネスロジック層に配置されるプログラムは1つではなく多数になり，開発量が増えるのである。

　しかし，だからといって，「開発量が増える」ということと「開発者の負担が増す」ということは必ずしも同一視できない。今日求められている業務システムは大規模化・複雑化する傾向にあり，一般的に一人の開発者がその任のすべてを負うことはない。むしろ，複数の開発者が共同で開発を進めてゆくのが実情のはずである。この場合，開発単位が大きいよりも，むしろ小さいほうが，各開発者が分業で作業を進めやすく，デバッグ時にも問題点を切り分けやすくなる。また，ほかの業務アプリケーションとの業務間連動を図る場合にも，融通が利くというメリットもあるだろう。

　以上で説明してきたように，3階層アプリケーションモデルでは，データベースを処理する単機能のプログラムを多数開発し，それをビジネスロジック層に配置して部品として扱い，それらを組み合わせて呼び出すことで，多種多様な処理を実現する。これから順に3階層アプリケーションの構築方法を説明してゆくわけだが，3階層アプリケーションモデルにおいては，「ビジネスロジック層に配置するプログラムは，できるだけ小さくシンプルに」というのが原則である。小さくシンプルなプログラムであれば，プログラミングのミスが混入することが少なくなるし，メンテナンスも楽になる。大きくて複雑なプログラムをビジネスロジック層に収めてしまうと，メンテナンス面で不利になることはもちろんだが，Windowsプラットフォームで構築する場合は，それ以外にもパフォーマンスが低下するという問題もある。Windowsプラットフォームにおけるパフォーマンス問題については，Chapter 4で詳しく説明する。

prev Chapter 1　6/11 next