Java 3 層アーキテクチャの原理と機能の概要 (図)

この記事では主に Java の 3 層アーキテクチャの概念と機能を紹介します 必要な方は 3 層アーキテクチャを参照してください

3 層アーキテクチャは、ビジネス アプリケーション全体を次のように分割します。 (UI)、ビジネスロジック層(BLL)、データアクセス層(DAL)。レベルを区別する目的は、「高凝集性、低結合性」という考え方です。

コンセプトはじめに

1. プレゼンテーション層 (UI):

平たく言えば、これはユーザーに表示されるインターフェイス、つまり、ユーザーがシステムを使用するときに表示され、得られるものです。

2. ビジネス ロジック層 (BLL): 特定の問題に対する操作は、データ層での操作およびデータのビジネス ロジック処理であるとも言えます。

3. データ アクセス層 (DAL): この層によって実行されるトランザクションは、データの追加、削除

、変更、検索などのためにデータベースを直接操作します。

概要

ソフトウェア アーキテクチャの設計において、階層構造は最も一般的で重要な構造です。 Microsoft が推奨する階層構造は、一般に下からデータ アクセス層、ビジネス ロジック層 (ドメイン層とも呼ばれます)、プレゼンテーション層の 3 層に分かれています。 3 層構造の原則:

3 つのレベルでは、システムの主要な機能とビジネス ロジックがビジネス ロジック層で処理されます。

いわゆる 3 層アーキテクチャでは、クライアントとデータベースの間に、

コンポーネント層

とも呼ばれる「中間層」が追加されます。ここで言う 3 層システムとは、単に 3 つのマシンを配置するという 3 層のアーキテクチャを意味するものではありません。B/S アプリケーションだけが 3 層のアーキテクチャであるわけではありません。 3 層システムとは、これら 3 つの層が 1 台のマシン上に配置されている場合でも、3 つの層の論理を指します。

3 層システム アプリケーションは、ビジネス ルール、データ アクセス、合法性検証、その他のタスクを中間層に配置して処理します。通常、クライアントはデータベースと直接対話しませんが、COM/DCOM 通信を通じて中間層との接続を確立し、中間層を通じてデータベースと対話します。

各層の役割

1: データアクセス層

: 元のデータではなく、主に元のデータ(データベースやテキストファイルなど)に対する操作層です。データベースではなくデータの操作であり、具体的にはビジネス ロジック層またはプレゼンテーション層にデータ サービスを提供します

2:

ビジネス ロジック層: 主に特定の問題に対する操作であり、データに対する操作としても理解できます。データ ビジネス ロジック処理の場合、データ レイヤーがビルディング ブロックである場合、ロジック レイヤーはこれらのビルディング ブロックの構築です。 3 そして変化により、ロジック層はサービスを完璧に提供できるようになります。

区別する具体的な方法

1: データ アクセス層: 主に、データ層に論理処理が含まれているかどうかによって異なります。実際、各 関数 は主にデータ ファイルに対するさまざまな操作を実行します。他の操作については心配しないでください。

2: ビジネスロジック層: 主にデータ層の操作を担当します。つまり、いくつかのデータ層操作を組み合わせます。 3: プレゼンテーション層: 主にユーザーリクエストを受け入れてデータを返し、クライアントにアプリケーションアクセスを提供します。 プレゼンテーション層

は、ユーザーに最も近い最も外側の層(最上位層)に位置します。データの表示とユーザーによるデータ入力の受信に使用され、ユーザーに対話型インターフェイスを提供します。

ビジネスロジック層

ビジネスロジック層（ビジネスロジック層）は、間違いなくシステムアーキテクチャの核となる価値を反映する部分です。その焦点は主に、ビジネスルールの策定、ビジネスプロセスの実現、およびビジネスニーズに関連するその他のシステム設計にあり、言い換えれば、システムが扱う分野（Do

main

）のロジックに関連しています。多くの場合、ビジネス ロジック層はドメイン層と呼ばれます。

たとえば、Martin Fowler は、著書『Patterns of Enterprise Application Architecture』の中で、アーキテクチャ全体を 3 つの主要な層 (プレゼンテーション層、ドメイン層、データ ソース層) に分割しています。ドメイン駆動設計の先駆者であるエリック・エヴァンスは、ビジネス ロジック層をより詳細に分割し、アプリケーション層とドメイン層に細分化し、階層化によってドメイン ロジックとドメイン ロジック ソリューションをさらに分離しました。

ビジネス ロジック層は、システム アーキテクチャにおいて重要な役割を果たし、データ アクセス層とプレゼンテーション層の間に位置し、データ交換においてリンクの役割を果たします。この層は弱結合構造であるため、層間の依存関係は下向きであり、上位層の設計を変更しても、それが呼び出す最下位層には影響しません。

レイヤードデザイン中にインターフェースを設計するという考えに従う場合、この下向きの依存関係も弱い依存関係になるはずです。したがって、インターフェイス定義を変更せずに、理想的な階層化アーキテクチャは、抽出可能性と置換可能性をサポートする「ドロワー」アーキテクチャである必要があります。このため、ビジネス ロジック層の設計は、2 つの異なる役割を果たすため、スケーラビリティをサポートするアーキテクチャにとって特に重要です。

データ アクセス層の場合は呼び出し元、プレゼンテーション層の場合は呼び出し先です。依存関係と依存関係はビジネス ロジック層で複雑に絡み合っています。依存関係の分離をどのように実現するかは、ビジネス ロジックの実装に加えて設計者の課題となります。

データ層

データアクセス層: 永続化層とも呼ばれるその機能は、主にデータベースシステム、バイナリファイル、テキストドキュメント、またはXMLドキュメントにアクセスできます。

簡単に言うと、データテーブルに対してSelect、Insert、Update、Deleteの操作を実装することです。 ORM 要素を追加する場合は、オブジェクト エンティティの永続化だけでなく、オブジェクトとデータ テーブル間の マップping も含まれます。

利点と欠点

利点

1. 開発者は構造全体の特定の層のみに集中できます。

2. 元の実装層を新しい実装に置き換えるのは簡単です。 3. レイヤー間の依存関係を減らすことができます。

4. 各レイヤーでのロジックの再利用に役立ちます。

6. 構造がより明確になります

7. 後のメンテナンス時のメンテナンスコストとメンテナンス時間が大幅に削減されます

デメリット

1.これは自明のことです。階層構造が採用されていない場合、多くの企業はデータベースに直接アクセスして対応するデータを取得できますが、現在は中間層を介してアクセスする必要があります。 2. 場合によっては、段階的な変更が発生する可能性があります。この修正は特にトップダウン方向に反映されます。プレゼンテーション層に機能を追加する必要がある場合、その設計が階層構造に確実に準拠するようにするために、対応するコードを対応するビジネス ロジック層およびデータ アクセス層に追加する必要がある場合があります。

3. 開発コストの増加。

ルール

3 層構造のプログラムは、プロジェクトが 3 つのモジュール (DAL、BLL、WebUI) に分割されていることを意味するものではありません。 SQL ステートメントや ストアド プロシージャ 呼び出しが少ない (またはまったくない) 場合、これらのステートメントはデータを変更しないことが保証されていますか?

2. UILyer が削除された場合でも、プロジェクトはインターフェース/

API

レベルですべての機能を提供できますか? 3. 類似した環境の他のプロジェクトに DAL を移植できますか?

すべての答えが YES でない場合、そのプロジェクトは移植できないと考えられます。厳密な意味での 3 層プログラム。3 層プログラムには、同意して従う必要のあるルールがいくつかあります。 1. 最も重要なことは、UI 層はシェルとしてのみ使用でき、これを含めることはできないということです。あらゆる BizLogic 処理プロセス

2. 設計は UI ではなく BLL から開始する必要があります。BLL レイヤーは、

オブジェクト指向

の方法ですべての BizLogic を実装する必要があります

3. データ レイヤーが単純であるかどうか。 SqlHelper、またはマッピング

クラス

は、ある程度の抽象化までシステムに依存しないようにする必要があります

4. などのリモート オブジェクト テクノロジが使用されているかどうか、デプロイ中に実際に別のサーバーにデプロイされるかどうかに関係なく、場合によってはそのような考慮が必要になり、さらに負荷分散による複数のサーバーのクラスタリングも考慮する必要があります

そのため、プロジェクトに 3 層/多層設計を適用するかどうかを検討するときは、まず次のことを行う必要があります。実際、ほとんどのプログラムでは、WebApplication を開くだけで十分であり、非常に複雑な

プロジェクト要件 を解決するために多層構造を使用する必要はありません。

とCOM+(Enterprise Service), 还是Remoting, 还是WebServiceMVC

の違い

MVC (Model-View-Controller) は、ドメイン オブジェクトと UI プレゼンテーション レイヤー オブジェクトを区別するために使用できるデザイン パターンです。

これはアーキテクチャ レベルでも同じですが、違いは他の 2 つの層にあります。

3 層アーキテクチャで定義されていない Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model の概念は、MVC のモデルの概念とは異なります。「3 層」の典型的なモデル層はエンティティ クラスで構成されますが、MVC ではビジネスで構成されます。データから構成されるロジックとアクセス。

以上がJava 3 層アーキテクチャの原理と機能の概要 (図)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。