3つの層:UI(インターフェース)、BLL(ビジネスロジック層)、DAL(データアクセス層)これら3つは必須で、BLLとDALのクラスは公開クラスです。なぜなら、UIはBLLを呼び出す必要があり、BLLはDAL、そしてUTILITY(データベースに接続し「追加、削除、変更、チェック」といった基本的な操作を実行する基盤メソッド)だからです。 さらに、ENTITY(データテーブルをマッピングする)やCommon(このライブラリは一般的にデータ検証メソッドや制御操作メソッドなどの一般的なメソッドを配置します)などのエンティティレイヤーも存在します。 簡単に言えば、それは データベースからのデータにアクセスすることはデータアクセス層です 関連データのビジネス関係を整理することは、ビジネスロジックの一層です 集約されたデータの表現は、これが表現層であることを示しています。
ちなみに、いくつか情報を見つけるのを手伝いました: 良い階層構造は、開発者の労働分担をより明確にします。 レイヤー間のインターフェースが定義されると、異なる論理設計を担当する開発者がそれぞれの努力を分散させ、手を取り合って作業できるようになります。 例えば、UI担当者はユーザーインターフェースの体験と運用だけを考慮すればよく、ドメインデザイナーはビジネスロジックの設計に専念でき、データベースデザイナーは煩雑なユーザー操作を気にする必要はありません。 各開発者のタスクが確認され、開発の進捗は迅速に改善されます。
ルーズカップリングの利点は明らかです。 もしシステムが階層的でなければ、その論理は密接に絡み合い依存しており、誰も代わりがいけません。 一度変化が起こると、それは全身に影響を及ぼし、プロジェクトへの影響は非常に深刻です。 レイヤー間の依存を減らすことは、将来のスケーラビリティを保証するだけでなく、再利用性においても明らかな利点をもたらします。 各関数モジュールが統一インターフェースを定義すると、同じ関数を繰り返し開発することなく各モジュールから呼び出すことができます。
良好な階層構造設計を行うためには、標準も不可欠です。 このシステムは一定の標準化レベルがあって初めて、スケーラブルで置き換え可能になります。 層間の通信はインターフェースの標準化も必然的に保証します。
|