ホームページ  >  記事  >  バックエンド開発  >  .NET 論理階層化アーキテクチャの分析

.NET 論理階層化アーキテクチャの分析

怪我咯
怪我咯オリジナル
2017-04-05 13:31:351754ブラウズ

1. 基礎知識の準備:

1. 層の原則:

(1) 各層は上位層からの呼び出しにインターフェースを使用します。
(2) 上位層は下位層のみを呼び出すことができます。
(3) 依存関係は、緩やかな相互作用と厳密な相互作用の 2 つのタイプに分類されます。

2. ビジネスロジック分類:

(1)アプリケーションロジック。
(2)ドメインロジック。

3. 採用層:

(1) プレゼンテーション層(ユーザーインターフェイス層):ドメインに依存しません。
(2)サービス層(アプリケーション層):アプリケーションロジック。
(3)ビジネスロジック層(ドメイン層):ドメインロジック。
(4) 共有レイヤー:共通コードを提供します。
(5)実装層:インターフェースの実装を提供します。

4. 合意:

(1) ドメイン層はデフォルトでドメインモデルを採用する
(2) データアクセス層はデフォルトでドメインモデルを参照する必要がある

2. 階層化アーキテクチャ

3 つの階層構造 基本的な層は、プレゼンテーション層、ビジネス ロジック層、データ アクセス層です。ビジネスロジック層をビジネスロジックの分類に従ってサービス層とドメイン層に分解すると、3層はプレゼンテーション層、サービス層、ドメイン層、データアクセス層の4層に拡張されます。データ アクセス層は通常、層間に双方向の依存関係を作成するドメイン モデルを理解する必要があります。通常、次の 2 つの解決策があります:

1. ドメイン モデルを共有層に配置します:

評価。 : PetShop このモデルには多くの欠点があります。ビジネス ロジック層はその名にふさわしいものではなく、ドメイン モデルは実際にはデータ モデルであり、層間の依存関係を維持し、より多くの依存関係を導入します。明らかなデータ駆動型 のアイデアはそうなります。ドメインを中心として考えないでください。

2. ビジネスロジック層でデータアクセスインターフェースを定義する:

評価: NopCommerce はこのモデルを採用しています サービス層が分離され、リソースライブラリの命名方法が採用されていますが、NopCommerce は DDD ではありません。このアーキテクチャは、ドメイン モデルとインターフェイス分離の原則を採用した一般的な 3 層アーキテクチャです。欠点: データ領域を除けば、他の特定の技術的依存関係がビジネス ロジック層から分離されていません。

3. DDD レイヤ化:

DDD レイヤ化は、ビジネス ロジック層をアプリケーション層 (サービス層) とドメイン層の 2 つの部分に明確に分割します。同時に、データ アクセスやその他のインターフェイスの特定の技術実装部分がインフラストラクチャ層に統合されます。

1.独自のDDD階層化:

評価: 利点は、特定の技術実装がドメインから分離され、インフラストラクチャ層の再利用の価値が高まることです。欠点は、共有と実装の概念がインフラストラクチャ層の細分化に使用されていないため、インフラストラクチャ層でウェアハウスを実装するときに逆依存関係が生じることです。ただし、単一プロジェクトのソリューションでは影響はありません (

の形式的な依存関係のみ)。 namespacelevel ) )、ただし、.NET マルチプロジェクト ソリューションでは、ウェアハウジングの実装は、インターフェイスの分離を通じてデータ アクセス層に似たものにのみ分離できます。

2. DDD階層化の改善:

評価: インフラストラクチャ層は、共有層と実装層の両方の特性を備えています。利点は、ドメインが最終的に形式的にコアになることであり、インフラストラクチャ層でウェアハウスを実装するときにドメイン モデルを参照できないという恥ずかしさも解決されることです。欠点は、共有と実装の概念にも区別がないことです。 。

3. 最新の DDD 階層化:

評価: 利点は、これが真にドメイン中心であり、インフラストラクチャ層がドメイン層を参照できないため、サービス層で再度適応する必要がないことです。 。依存関係反転の原則を使用して、特定のテクノロジーに対する各レイヤーの依存関係を完全に反転します。欠点: 依存関係の反転が過剰に適用されることも、単一プロジェクト ソリューションでは問題ありませんが、.NET マルチプロジェクト ソリューションでは、名前空間の形式で双方向の依存関係が発生します。インフラストラクチャ層は実装層としては基本的に再利用価値がありません。より良いアプローチは、図内のユーザー インターフェイス層とインフラストラクチャ層の位置を交換することです。

必要に応じて、上の画像に適切な共有レイヤーを追加することを検討してください。

4. アーキテクチャのトレンド:

(1) ビジネスロジックを核として、ビジネスロジックにもっと注目する。
(2) ビジネスロジック層の特定の依存関係を 1 つのレベルに分割し、一元管理します。
(3) ソリューション間でのコードの再利用よりも、ソリューション内の依存関係を減らすことに注意を払います。
④共有層と実装層の分離がますます反映される。たとえば、タマネギのアーキテクチャ。

以上が.NET 論理階層化アーキテクチャの分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。