私は、ここで少しの現実を和らげた、知覚された「ベストプラクティス」に興味があります。
Web アプリケーションでは、Web 層が DAL に直接アクセスできるようにしますか? それとも、最初に BLL を経由する必要がありますか?
具体的には、「ビジネス ロジック」が実際には関与しないシナリオについて話しています。たとえば、単純なクエリのように、「姓が 'Atwood' のすべての顧客を取得する」などです。あらゆる種類のロジックが絶対に存在するシナリオは、BLL を通過するので、それをmooと呼びましょう。
このメソッドを BLL オブジェクト内にカプセル化することもできますが、多くの場合、署名が DLL オブジェクトの署名とまったく同じであり、クエリを DLL に委譲する 1 つのライナーと同じくらい単純なコードになる場合は、やや無意味に思えます。 .
BLL オブジェクトを使用する前者を選択した場合、これらのオブジェクトを何と呼びますか? (クエリ レイヤーを DLL に提供する以上のことはしないと仮定します)。ヘルパー？クエリプロバイダー?
考えてください。
よろしく
マーティ
私はここのほとんどの投稿に同意しません。
私は自分のデータ層を Web 層と呼んでいます。WEB/UI 層の間に何もなければ、「念のため」層を作成しても意味がありません。最適化前です。もったいないです。ビジネスレイヤーが「私を救った」ときのことを思い出すことはできません。それがしたことは、より多くの作業、重複、およびより高度なメンテナンスが作成されたことだけです. 私は何年もの間、ビジネスレイヤーをサブスクライブしました->レイヤー間でエンティティを渡すデータレイヤー。私はいつも、何もしないパススルー メソッドを作成するのが汚いと感じていました。
Eric Evans によって Domain Driven Designを紹介された後、私は理にかなったことをしています。UI とデータ レイヤーの間に何もない場合は、UI でデータ レイヤーを呼び出します。
将来の変更を可能にするために、すべてのデータ層クラスをインターフェイスでラップします。UI ではインターフェイスを参照し、依存性注入を使用して実装を管理します。これらの変更を行った後、それは新鮮な空気の息吹のようでした. データ層と UI の間に何かを挿入する必要がある場合は、サービスを作成します。
私が行ったもう 1 つのことは、プロジェクトの数を減らすことでした。データ レイヤー、ビジネス ロジック、ビジネス エンティティ、および何らかの種類の UI プロジェクトのプロジェクトを作成する前は、なんと苦労したことでしょう。
コア プロジェクト (エンティティ、ビジネス ロジック、データ レイヤー) と UI プロジェクト (Web、Web サービスなど) の 2 つのプロジェクトがあります。
詳細については、これらの人を見ることをお勧めします。
私の意見では、Web層とDAL（データアクセス層）の間で常にBLL（ビジネスロジック層）を使用する必要があります。
より「単純な」クエリのいくつかでは、BLLがDALを厳密に模倣することを感謝します（たとえば、すべての国をフェッチする、すべての製品タイプをフェッチするなど）が、正直なところ、あなたの例でも：
（「Atwood」という名前のすべての顧客を取得します）
ここには「ビジネスロジック」が表現されています。データレコードを名前でフィルタリングしたいという要望があります。
プロジェクトの開始からBLLを実装することにより、必要に応じて検証または追加の「ロジック」を挿入することが非常に簡単になります（プロジェクトが商用アプリケーションの場合、その必要性は最終的にはほぼ確実に発生します。プロジェクトの開始時にはありません）。次のような追加のロジックを追加します。
今年10000ドル以上を費やしたすべての顧客を取得します
また
「Atwood」という名前の顧客が1000ドルを超える商品を購入することを許可しないでください
このロジックをWeb層にクローバーしようとするのではなく、真のBLLが関与している場合に非常に簡単になります。
上記の種類のクエリでは、この機能を実装するために特別に定義された関係で結合する必要がある複数のエンティティとデータベーステーブルについてほぼ確実に話していることに注意してください。DALを直接操作してこれを達成しようとすると、複数のエンティティとクラスを処理するため、面倒になります。ここでのBLLは、Web層コードを大幅に簡素化します。これは、BLLが、大幅に簡素化されたインターフェイスの背後にあるエンティティの関係をカプセル化するためです。
この「関心の分離」は、ユーザーインターフェイスを変更する必要が生じた場合に、ますます重要になります。
現在、少なくとも2つの別々の機会に、Webサイトのユーザーインターフェイスを備えた商用Webアプリケーションに取り組んでおり、最終的には（ソフトウェア製品内でのより高度な統合を求めるクライアントから生じるビジネスニーズのために）Webサービスインターフェイスの作成を求められました。 Webサイトとまったく同じ機能を提供します。
Web層にビジネスロジックを組み込んだ場合、Webサービスを実装するときに、そのロジックを複製して書き直す必要がありました。つまり、すべてのビジネスロジックがBLLクラス内にカプセル化されていることを確認しました。つまり、一連のWebサービスインターフェイスメソッド呼び出しを設計し、これらをBLLクラスのメソッド呼び出しに対してプラグインするだけで済みました（実際に使用したのはWebサービスAPIを簡素化するための場所のファサードデザインパターン）。
全体として、DALとWeb層の間にBLLレイヤーを含めない理由は考えられません。
最も簡単なのは、BLLがDALを厳密に「模倣」する場合です。そうです、コードと機能が重複しているように見えますが、もう少し入力するだけで、実装も比較的簡単になります。
それがより複雑な場合（重要なビジネスロジックが最初から存在する場合など）、関心の分離は繰り返しを減らすのに役立ち（DRYの原則）、同時に将来の継続的なメンテナンスを大幅に簡素化します。
もちろん、これはあなたがこれらすべてを「手作業で」行っていることを前提としています。必要に応じて、多数のORMを利用することで、DAL / BLL/UIレイヤーを大幅に簡素化できます。（つまり、LINQ-to-SQL /エンティティ、SubSonic、NHibernateなど）
BLL オブジェクト (これらは一体何なのですか? ドメイン オブジェクトはありますか?) とサービスを区別する必要があります。ドメイン オブジェクトは、データ アクセス層とは何の関係もありません。Web層に関する限り、IRepository自由に使用できる他のサービスと同じように、リポジトリを扱うことができます.
つまり、要点は次のとおりです。はい、Web 層は、DAL がカプセル化されたプロパティであり、標準のサービス層サービスとして表されている場合、DAL を直接使用できます。
DLL に対して同様の呼び出しを行う BLL の 1 行であっても、抽象化により、他のレイヤーに影響を与えることなく、そのレイヤーにビジネス ロジックを追加できます。今はありそうにないように見えるかもしれませんが、アプリケーションをサポートしなければならない人は誰でも、変更が発生したときにこのようなパターンを使用してくれたことに感謝します.
名前付けに関しては、NameChange などのコア オブジェクトがあり、次に名前変更オブジェクトを受け入れる人である BLL オブジェクトがあり、次に Person と呼ばれる DAL/Entity オブジェクトがあります。ビジネス Person オブジェクトは BLL 名前空間内にあり、DAL/Entity Person オブジェクトは DB 名前空間内にあります (最初に構築した場合は DAL を選択したでしょう)。
このレイヤーを、Web 層から DAL をカプセル化するコントローラー クラス [レイヤー] と呼びます。コントローラー層には、ビジネス ロジックがある場合とない場合があります。これは、DAL をプレゼンテーション層から分離し、[ある程度] 独立した状態に保つのに役立ちます。
アクセスにはファサード パターンを使用する傾向がありましたが、それを使用するプロジェクトはかなり大きいですが、小規模なプロジェクトではやり過ぎになる可能性があると思います。
基本的に：
UI -> BusFacade -> BusinessLogic -> DalFacade -> DataAccessLayer
ファサードは UI からの優れた/クリーンなアプローチを実現し、単一のエントリ ポイントに多数のメソッドがあるため、命名規則を標準化する必要があります。
BusFacade.GetCmsSiteMap()
BusFacade.GetProductGroup()
などなど
プレゼンテーション レイヤーから DAL に直接移動することは可能ですが、認証が必要なことが多い BLL をスキップしています...