1 ページを 3 レイヤーに変換する作業を行っています。
利点は、より組織化されていることだと思います。
現在 3 つのレイヤーがあるため、何が起こっているのか混乱しており、3 層とは何かを明確に理解していないことに気付きました。
これは私が知っている、または私が知っていると思っていることです
データ アクセス レイヤー = すべての接続/値を取得します
Business Access Layer = DAL からこれらの接続と値を実行します。よくわかりませんが、エラーチェックはここで行われますか?
プレゼンテーション層 = ここがもっと混乱するところです...この部分は BAL を呼び出しますか? これが本当なら、なぜ3つのレイヤーがあるのですか?
プレゼンテーション層はユーザーと対話し、要求を取得して情報を表示します。例として銀行アプリケーションを使用してみましょう。ユーザーは自分のアカウントにログインし、残高を取得し、いくつかの発見を転送したいと考えています。
プレゼンテーション層: ユーザーにログイン プロンプトを表示し、ユーザーのログイン情報を取得し、正常にログインしたことを伝え、残高を表示し、資金を送金するオプションを提供し、送金の詳細を取得し、送金が承認されたことをユーザーに伝えます。
ビジネス アクセス レイヤー: ユーザーのログイン情報を検証します。ユーザーに表示する残高を計算します。譲渡を許可することを決定し、承認します。
データ アクセス層: ユーザーのログイン情報を格納します。口座残高情報、保有資金などを保存します。
基本的：
データ アクセス層は情報を格納します。ビジネス アクセス レイヤーは、取得する情報を決定し、それに基づいて決定を下し、結果を渡します。プレゼンテーション層は、ユーザーから情報を取得し、ユーザーに情報を提供します。
まず、「ティア」は「レイヤー」と同義ではありません。
レイヤーは論理的な分離です。
層は潜在的に物理的な分離であり、通常はマシンまたはプロセス レベルにあります。
(参照: http://pranshujain.wordpress.com/2006/09/15/layers-and-tiers/ )
=======
それはさておき、これらの3つのレイヤーの理由は、それらを自由に交換できるようにすることです. たとえば、複数のプレゼンテーション レイヤー (Web、モバイル、デスクトップ アプリ) があるとします。ここでの目的は、プレゼンテーションを他のすべてのものから分離して、さまざまなプレゼンテーション コードをすべてやり直すことなくビジネス ロジックを変更できるようにすることです。
ビジネス オブジェクト層は、すべての通常のロジックをカプセル化して適用するために存在します。たとえば、生年月日は今日の日付より前でなければならないと言うかもしれません。多くの開発者は、これをストレージとプレゼンテーションの両方から分離することを好みます。
データ アクセス層は、ビジネス オブジェクトから実際のストレージ メカニズムにデータをマーシャリングする役割を果たします。物事を SQL Server、Oracle、またはフラット ファイルに保存することを決定でき、アプリケーションの残りの部分はいずれにせよ気にするべきではないという考えで。
============
これらのレイヤーはすべて必要ですか? いいえ、しかし多くのアプリケーションでは、物事を変更するときに役立ちます。
さて、Tierについて。デスクトップまたはブラウザーは、1 つの層と見なすことができます。Javascript コードと HTML はここで実行されます。デスクトップ アプリをお持ちの場合は、ここに保存されます。
もう 1 つの層は、Web サーバーまたは Web サービス インターフェイスです。これは、クライアント側でのレンダリングと使用のために html を提供する役割を果たします。通常、プレゼンテーション レンダリングとビジネス オブジェクト レイヤーの両方が格納されます。
さらにもう 1 つの層は、実際のストレージ メカニズムです。たとえば、SQL Server または Oracle です。
アーキテクチャがどれだけ進んでいるか (またはずさんな...) かに応じて、5 つまたは 6 つの異なる Tier を持つ可能性は十分にあります。ただし、その数は通常 2 で、3 以下です。
また、レイヤーが 1 つまたは 12 しかない可能性も十分にあります。ただし、ここでの数は通常 2 ～ 3 です。これも、アーキテクチャによって異なります。
この記事は良い要約のようです: http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture
ここで強調したい点は、各層を異なる環境で実行できることです。たとえばasp.netを使用して、Webサーバーでプレゼンテーション層を実行できます。Windows サービスや WCF サービスなどを使用して、別のサーバー (アプリケーション サーバー) でビジネス アクセス レイヤーを実行できます。最後のレイヤーは、データベース サーバー上またはその近くに配置できます。
レイヤーを異なる物理的な場所に潜在的に分離できるという利点は、スケーラビリティを向上できることを意味します。例として、Web サーバーが大量のリクエストで苦労している場合が考えられます。ビジネス アクセス層を呼び出す 2 つの Web サーバーを用意することにしました。
もう 1 つの利点は保守性です。すべてのデータ アクセス コードを並べて配置すると、データ アクセス レイヤーの問題をデバッグしやすくなります。探しているものを見つけやすくするために、コードをおそらく 3 分の 1 削減するプロジェクトがあります。
さらに別の利点は、交換可能性です。もうasp.netを使いたくないとしましょう。PHP Web レイヤーを交換して、.NET ビジネス ロジックとの通信をより簡単に行うことができます。
基本的に、私が言及した利点は、ほとんどモジュール性/粒度の利点です。