何年にもわたって、開発者が異なれば、n 層システムの開発における層を構成する基準も異なることに気付いたので、stackoverflow でのコンセンサスがどのようなものであるかに興味がありました。
別の層と呼ぶには、別の論理レイヤーで十分ですか? それとも別の層と呼ぶには、別のサーバー (物理または仮想) にデプロイできる必要がありますか?
質問の言い方を少し変えてみましょう。呼び出しメカニズムがイン プロセス、スレッド ローカル、またはアパートメント ローカルのみである場合、クラスがライブラリまたはパッケージにどのように編成されているかに応じて、2 つの異なる層であると主張することは可能ですか?
別の論理レイヤーで、それをティアと呼ぶことができます。必ずしも別のサーバー上にある必要はありませんが、他のレイヤーからの定義された分離により、確かにそれが可能になります。
例として、私が3層システム（db、dll、aspページ）と呼ぶものを単一のサーバーで実行していました。いくつかの定義によれば、これは単層システムです。これでデータベースが別のサーバーで実行され、必要な変更は接続文字列のみでしたが、これは2層ソリューションになりますか？
そのため、ティアの概念は、実際に実行する必要があるのではなく、別々のマシンで実行する機能に関するものだと感じています。それは私にはもっと一貫しているようです。
私にとって、物理層とは、異なる物理マシンで実行されるように設計されたシステムの一部を意味します。はい、いつでもデータベース接続文字列を別のサーバーに向けることができますが、DALがおしゃべりすぎて、n + 1で無制限のレコードセットの問題がある場合は、ネットワーク遅延によって非常に速く停止します。
一方、論理層は、関心の分離、凝集度、結合度の長所をサポートします。厳密には、個別のアセンブリにある必要はありません。名前空間でうまくいきます。すべきではないとわかっているクラスを呼び出さないでください。NDependがお手伝いします。
レイヤーとティアの概念は、しばしば同じ意味で使用されます。ただし、かなり一般的な見方の1つは、実際には違いがあり、レイヤーはソフトウェアソリューションを構成する要素の論理的な構造化メカニズムであり、ティアはシステムインフラストラクチャの物理的な構造化メカニズムであるというものです。
Ref。
レイヤーは結合を最小限に抑えるためのメカニズムです。それらは論理的です。層は、パフォーマンスを最大化するか、セキュリティ リスクを無効にするように設計されています。それらは物理的です。それらは実際には同じではなく、人々がそれらを同じ意味で使用しようとする理由がわかりません.
Web アプリケーションの大部分は、デフォルトで 3 層 (ブラウザー、Web サーバー、データベース サーバー) です。イントラネット アプリの大部分は 2 層 (クライアント、データベース サーバー) です。ただし、どちらの場合も、UI レイヤー、ビジネス レイヤー、データ レイヤーを構築します。それらは関心を分離し、保守性のためにコードを構造化するのに役立ちます。また、どちらの場合も、通常、それらすべてを 1 つのボックスに展開することになります。Web サーバーまたはクライアント ワークステーション。したがって、層と層は一致しません。
定義を打ち出す必要があると言わざるを得ません。私は通常、層を機能と責任の論理的な分離と見なし、層を物理的な分離の要件または能力と見なします。一部のレイヤーには複数の層があり、一部の層はレイヤーにまたがっている場合があります。私は通常、必要に応じて、および/または構成を介して必要に応じて物理的な分離を提供する機能を備えたサービスレイヤー層を使用します。
したがって、質問/コメントをフォローアップします。データベースのストアドプロシージャに多数のロジック（ビジネスまたはその他）がある場合、それも層と見なす必要がありますか？Service Broker for Microsoft SQLServerなどのデータベースエンジンの機能を利用している場合はどうなりますか？それ自体が2つの層を持っていると見なすことができます。
また、バックグラウンドサービスやデーモン、それらは別個の層やレイヤーですか、それとも既存のものに属していますか？
コンピューティングにおける「階層」という用語の歴史を見てください。デスクトップ/ミニ/メインフレームでの 1 層コンピューティングについて誰も言及していません。クライアント サーバーの時代には、誰も 2 層コンピューティングとは言いませんでした。3 層は、クライアント/サーバーとその間のミドルウェア (メッセージ指向のミドルウェアとトランザクション ブローカー) のアーキテクチャ モニカになりました。n 層は、「EAI - またはエンタープライズ アーキテクチャ統合」という別の用語とともに普及したと思います。これはサービス指向アーキテクチャとまったく同じ考え方でしたが、ベンダの実装のほとんどが独自仕様か、標準ベースであるが非常に高価であるか、またはその両方であったことを除いては. XML-RPC、SOAP、および REST が登場した後、彼らはそれを「Web サービス」と呼び、その背後に EAI 原則を適用して、SOA (サービス指向アーキテクチャおよびエンタープライズ サービス バス) に到達しました。
私が言いたいのは、これらの用語はどれも物理的な分離を暗示していないということです...それは常に機能の論理的な分離に関するものでした。これらの論理アプリケーション層の多くは、水平方向のスケーラビリティのために物理的に分離できるように、ステートレスになるように設計されていました。
私はGarry Shutlerに同意しますが、多くの層が単一のプロセス/スレッドまたは同じアセンブリにも存在する可能性があることを付け加えます. 物理的な (ハードウェア、実行可能ファイルの分離、またはバイナリの分離) 分離よりも重要なのは、開発者向けのコードのレイアウト (私見) です。aspnet アプリの場合と同様に、同じ 1 つの dll に、データ アクセス、ドメイン、およびプレゼンテーションの 3 つの層すべてを含めることができます。