私はアプリケーションレイヤーについて読んでおり、次のプロジェクト（c＃、. Net）でこのデザインを使用したいと考えています。いくつかの質問：
レイヤーの分離は名前空間を通じて行われますか？Project.BLL.Whatever、Project.DAL.Whatever
レイヤー、コンポーネント（Project.BLL.Component1）、またはコンポーネント、レイヤー（Project.Component1.BLL）で分離する方が適切ですか？
私のDALの場合、このレイヤーはさまざまなクラスを使用してさらに編成されますか？すべてのデータベース呼び出しが単一のクラスに入れられる場合、組織はありません。これらを異なるクラスまたは名前空間に分割する方が良いでしょうか？
DALクラスは通常静的ですか？毎回そのメソッドの1つを呼び出す前にDALオブジェクトをインスタンス化するのは面倒です。
これらのレイヤーで正しい方法で物事を行うためのその他のヒントをいただければ幸いです。
回答:
いいえ、それは単体テストをはるかに難しくします。依存関係の注入を使用して、各データアクセスクラス（IDatabaseServiceなど）のコンストラクターに依存関係を渡す必要があります。次に、次のように、データアクセスオブジェクトをビジネスオブジェクトに渡します。
BusinessObject businessObject = new BusinessObject（new DataAccessObject（new DatabaseService（）））; businessObject.PerformOperation（）;
各ビジネスオブジェクトには、複数のデータアクセスオブジェクトが必要な場合があります。GUIコードも1つ以上のビジネスオブジェクトを使用します。一部のビジネスオブジェクトは、データアクセスオブジェクトを必要としない場合がありますが、IDatabaseServiceを直接使用しないでください。
質問1と2については、Matthewの回答を使用してください。
デスクトップアプリケーションのDALを構造化する最良の方法を理解するために、かなりの時間を費やしてきました。そして、最善の方法は、実際にはアプリケーションのニーズによって異なります。私のアプリの1つで、データベーステーブルごとにDAクラスを作成する道を進み、中央（つまりシングルトン）のDataProviderクラスに登録し、CRUDを処理しました。次に、各DAクラスは、すべてのテーブルデータをRAMにキャッシュするかどうか（パフォーマンス！）、および/または他のコンピューターで実行されている他のクライアントで自動クライアント更新をトリガーする機能が必要かどうか（マルチユーザーを考える）並行性）。これにより、登録インターフェースに準拠するだけで、新しいDALクラスを非常に簡単に追加できます。
すべてのDALがこの種の機能を必要とするわけではありませんが、アプローチ自体（つまり、シングルトンデータプロバイダーと静的登録を使用した単純なDALクラス）によって、新しいクラスを追加し始めたときの作業がずっと楽になったことを学びました。
これが非常に単純なアプリケーションでない限り、CRUDをより高いレベルのクラスに組み込むことはお勧めしません。DALはデータストレージを抽象化したものです。将来のある時点でデータストレージを変更することを決定した場合（たとえMS SQLではなくMySQLを使用するだけであっても）、それは非常にありがたいことです。さらに、BLLオブジェクトは、ビジネスロジックの関係によって構造化されている必要があります。DALオブジェクトは、それらが表すストレージコンテナーのタイプによって構造化されます。違いは劇的です。
DALクラスを静的にしないでください。コーディング速度で得られるものは、テスト容易性と柔軟性で何回も失われます。