Business Logic Layer（BLL）はどのような用途に使用されますか？

データベースアプリケーションのグッドプラクティスを読んで、いわゆる「ビジネスロジックレイヤー」の支持者に頻繁に出くわし、自分のプロジェクトがそれを使用するのが最適かどうかを判断しようとしています（小さな個人プロジェクトです）。私の問題は、BLLがDALで処理できないこと（クエリの実行と結果のオブジェクトへのマッピング）を何も考えられないという事実にあるため、BLLは何もせずにDALを呼び出します。

たぶん、DALが何をすべきかについて、私は間違っているかもしれません。しかし、データベース管理アプリケーションのBLLにはどのような機能が期待されるのでしょうか？

私の小さなアプリケーションでは、通常、BLLはDALへのパススルーとして開始されます。大丈夫です。ビジネスルールを「発見」すると、BLLがそれらを配置します。また、テストを作成するときに、BLLに必要なものがたくさん見つかります。私自身の個人用アプリの場合、ビジネスルールを作成しますが、BLLは依然としてそれらを配置します。私にとって、BLLは時間とともに成長するものです。プロジェクトに長く携わるほど、そのBLLは大きくなります。

小さなプロジェクトでBLLとDALを組み合わせることを検討しますか？私は、髪型を変えるのと同じくらい頻繁にDALテクノロジーを変えるという事実を除いて、クライアントコードをそこから隔離するものが欲しいと思うかもしれません。

BLLは、ビジネスドメインの一部であり、データベースの一部ではなく、UIの一部ではないものを処理します（通常）。たとえば、顧客の年齢を使用して、特別なシニアの割引を受ける資格があるかどうかを判断します。DALはこれを行うべきではなく、単に顧客データを取得し、BLLが作業を行った後に割引データとともに格納する必要があります。DALは、CRUDに重点を置く必要があります。小規模なアプリケーションでは、2つの懸念事項が重複する場合があります。

アンドリュー、

ビジネスロジックレイヤーは、ドメイン駆動型開発を行い、ドメインのコアアクティビティに焦点を当てるときに最終的に得られるものです。プレゼンテーションレイヤー（GUI、Web）とインフラストラクチャレイヤー（DB、ネットワーク接続など）を取り除くと、銀行口座への入金など、ドメインの一部であるコア活動があります。これで、ビジネスレイヤーをモデル化し、プレゼンテーションやインフラストラクチャから分離した場合、Webやモバイルデバイスなどの他の用途に簡単に移植できます。それは開発について考えるためのきれいな方法であり、私が見たものから、残念なことにそれほど深刻に受け止められていません。

Eric Evans-Domain Driven Designを手に入れることをお勧めします。これは、開発努力をドメインに集中することを正当化する良い本です。確かに、それは少し中途半端な読み物ですが、それは勢いを増し、開発者が今日のシステムで何を間違っているのかについていくつかの強い信念を持っています。

特定の数の階層またはレイヤーが必要だということは何もありません。それはすべて、プロジェクトの複雑さに依存します。オタクディナーやレコードストアなど、MVCのサンプルアプリの多くを見てください。処理ロジックがほとんどないアプリケーションでは意味がないため、すべて2つのレイヤーを使用します。

ただし、アプリが小さい場合でも、通常はビジネスレイヤーとなる3番目のレイヤーを介して、プレゼンテーションレイヤーからデータレイヤーを抽象化することでメリットが得られる場合があります。これにより、プレゼンテーションレイヤー全体ではなく、1か所で変更を行うことができます。

ORMをLinqからSQL、Entity Framework（またはnhibernate）に変更するとします。プレゼンテーションはプレゼンテーションレイヤーに密接に結合する傾向があるため、プレゼンテーションレイヤーよりもビジネスレイヤーで変更する方が簡単です。

MVC、つまりModel View Controllerを理解している場合、アプリケーションアーキテクチャを同様の用語で考えることができます。モデルはデータレイヤーに類似しており、プレゼンテーションレイヤーはビューであり、ビジネスレイヤーはコントローラーです。

ドメイン駆動設計に関するDesolate Planetの回答を補完するもの：

ドメイン駆動設計の概念と非常に整合しているThe Onion Architectureもチェックしてください。

ビジネスロジック「レイヤー」がタマネギのコアであり、すべてのインフラストラクチャレイヤー（データアクセスレイヤーなど）がその外部依存関係であることに注意してください。これは、すべての外部インフラストラクチャの依存関係を模擬し、ドメインロジックを完全にテストできるため、テストに非常に役立ちます。

私の意見では、ビジネスロジック層は「純粋な概念的ソリューション」が存在する場所です。残りはインフラストラクチャの実装の詳細です。

ただし、アプリケーションによっては、この種のアーキテクチャを必要としない場合があります。アプリケーションがすべてデータセットCRUD操作である場合、「純粋な概念的ソリューション」は実際には空である可能性があり、必要なのはデータベース編集フロントエンドだけです。その場合、おそらくDALとUIレイヤーのみに焦点を合わせた方が良いでしょう。

この質問に対する答えは（IMHO）です：「DALを完全に置き換えても、ビジネスロジックコードを書き換える必要はありませんか？」

プレゼンテーションレイヤーのように考えてください。GUIを別のGUIに変更することはよくあることです。厚いデスクトップGUIはWebクライアント用に交換され、iPhoneクライアント用に交換されます。非常によく似たもの（たとえば、SQLServer DBをMySQLに置き換えたもの）を除いて、実際には交換されないため、BLL / DALについてこのように考えることはそれほど一般的ではありません。 APIを使用してアクセスされたサービスでは、レイヤーがどこで出会うかをより明確に把握できる場合があります。