すべての略語
•データアクセスレイヤーまたはDAL
データベースから直接、またはORMを介してデータを取得または変更します。 データはフィルタリングされますが、まったく処理されません。 ページの解析などを介して、他のソースからデータを取得することもできます。
•ビジネスレイヤーまたはBLL
DALを介してデータを処理します。 データが処理され、目的の形式に縮小されます。 これが最も興味深いレイヤーです。 これは、すべてのアプリケーションロジックが発生する場所です。
•サービスレイヤーまたはSL
この層は、大規模なアプリケーションでのみ見られます。 本質的に、これは他のアプリケーションからアプリケーションにアクセスするためのAPIインターフェースです。 この層については、この分野での私の極度の無知のため、説明しません。
•プレゼンテーションレイヤーまたはPL
実際にはデータ表示レイヤー。 BLLからのデータを、表現に必要なエンティティに処理します。
詳細分析
既に知っているように、プレゼンテーション層は、データを表示に必要な形式に変換するために使用されます。 同じロジックを持つアプリケーションは、異なる形式を持つことができます。 通常のソフトウェア、つまりウィンドウアプリケーションには、Webプロジェクトまたはコンソールプロジェクト以外の表示するクラスがあります。 アプリケーションのタイプごとに、PLのクラスのパッケージが必要です。 MVCプロジェクトの場合、これはコントローラーのセットです。 Webプロジェクトでは、コントローラーにはルーティングを制御する権利もありますが、一見すると、これはコントローラーにとってロジックが不適切であるように思えるかもしれませんが、BLLレイヤーでは許可されていません。
現在のアプリケーションのビジネスロジック全体を隠すにはビジネスレイヤーが必要です。アプリケーションプラットフォームがあらゆる種類のものであるのと同様に、アプリケーションデータもあらゆるソースからのものです。 このレイヤーは、論理的に関連するエンティティを1つの概念に変換します。 フォーラムを作成するタスクがあり、ユーザーのアカウントにすべてのユーザーのメッセージを表示する必要があるとします。これが応答であるかトピックであるかは関係ありません。 これらのエンティティは、メッセージエンティティに変換されます。 データベースエンティティをアプリケーション論理エンティティに変換することは、ビジネスレイヤーの主な責任の1つです。
DALレイヤーは、データベース、XMLファイル、APIサービスなどからのサンプルのレイヤーです。会社のデータソースごとに個別のDALレイヤーライブラリが必要ですが、ほとんどの場合、データベースのみがソースとして機能します。
上記のすべては、主に、さまざまなプレゼンテーションモード、さまざまなデータソース、および共通データを使用するさまざまなアプリケーションを持つ大規模プロジェクトに役立ちます。 また、普通の開発者にとっては、データ量の少ない1つのプラットフォーム用の小さなプログラムを作成する必要があるため、やり過ぎに見えるかもしれませんが、そうは思えません。 実際、レイヤー化はほとんどすべてのプロジェクトに大きなメリットをもたらします。 主な利点：コードは美しく、読みやすく、概念は混同されず、簡単に拡張できます。 リファクタリングが容易になります。これは、美しいアプリケーションにとって非常に重要です。 これらのルールは、小規模なプロジェクトでのみ無視でき、それ以上の改善が想定されない場合は可能です。
すべてがそうです。 不明な点や誤った記述がある場合は、コメントを記入して、修正を試みます。 ご清聴ありがとうございました。