3 層アーキテクチャ モデルの使用
論理設計モデルの基本的なフレームワークである 3 層アーキテクチャ モデルは、アプリケーション コンポーネントを 3 層のサービスに分割します。 これらの層は、ネットワーク上のさまざまなコンピュータ上の物理的な場所に必ずしも対応しているわけではなく、アプリケーションの論理レイヤーに対応します。 物理トポロジでのアプリケーションの分散方法は、システム要件に応じて変化する可能性があります。
各レベルに割り当てられているサービスの簡単な説明を次に示します。
プレゼンテーション層 (ユーザー サービス 層) は、ユーザーにアプリケーションへのアクセス権を付与します。 このレイヤーはユーザーにデータを提示し、必要に応じてデータ操作とデータ入力を許可します。 このレイヤーの 2 種類のメインユーザー インターフェイスは、従来のアプリケーションと Web ベースのアプリケーションです。 Web ベースのアプリケーションには、従来のアプリケーションで使用されるほとんどのデータ操作機能が含まれるようになりました。 これは、動的 HTML とクライアント側のデータ ソースとデータ カーソルを使用して実現されます。
Note
3 層アプリケーションでは、クライアント側アプリケーションは、中間層に配置されたサービス コンポーネントが含まれていないため、クライアント側アプリケーションはクライアントサーバー アプリケーションよりも細くなります。 これにより、ユーザーのオーバーヘッドは少なくなりますが、コンポーネントが異なるマシン間で分散されるため、システムのネットワーク トラフィックが多くなります。
中間層 (ビジネス サービス 層) は、ビジネス ルールとデータ ルールで構成されます。 ビジネス ロジック層とも呼ばれる中間層は、COM+ 開発者がミッション クリティカルなビジネス上の問題を解決し、主要な生産性の利点を達成できる場所です。 このレイヤーを構成するコンポーネントは、リソース共有を支援するために、サーバー コンピューター上に存在できます。 これらのコンポーネントを使用して、ビジネス アルゴリズムや法的規制や政府の規制などのビジネス ルールと、特定のデータベースまたは複数のデータベース内でデータ構造の一貫性を維持するように設計されたデータ ルールを適用できます。 これらの中間層コンポーネントは特定のクライアントに関連付けられていないため、すべてのアプリケーションで使用でき、応答時間やその他のルールが必要とするため、異なる場所に移動できます。 たとえば、単純な編集をクライアント側に配置してネットワークラウンドトリップを最小限に抑えたり、データ ルールをストアド プロシージャに配置したりできます。
データ層 (データ サービス 層) は、通常、データベースまたは永続的ストレージに格納されている永続的なデータと対話します。 これが実際の DBMS アクセス 層です。 ビジネス サービス レイヤーを介してアクセスすることも、ユーザー サービス レイヤーによってアクセスすることもできます。 このレイヤーは、(生の DBMS 接続ではなく) データ アクセス コンポーネントで構成され、リソース共有を支援し、各クライアントに DBMS ライブラリと ODBC ドライバーをインストールせずにクライアントを構成できるようにします。
アプリケーションのライフ サイクル中に、3 層アプローチは、再利用性、柔軟性、管理容易性、持続性、スケーラビリティなどの利点を提供します。 作成したコンポーネントとサービスを共有および再利用でき、必要に応じてコンピューターのネットワークに分散できます。 大規模で複雑なプロジェクトを単純なプロジェクトに分割し、異なるプログラマやプログラミング チームに割り当てることができます。 また、変更に対応できるようにコンポーネントとサービスをサーバーにデプロイすることもできます。また、アプリケーションのユーザー ベース、データ、トランザクション ボリュームの増加に合わせて、コンポーネントとサービスを再デプロイすることもできます。
関連トピック