複数のデータベースに到達する必要があるアプリケーションがあります。以前は、単一のデータベースにのみ到達する個別の DAL がありました。別のビジネス層が最上位にあり、特定の DAL のみに到達します。ビジネス レイヤーの上にあるアプリケーション (さまざまな Web サイト) は、データを共有する必要がある場合、任意の数のビジネス レイヤーを自由に呼び出すことができました。
これはしばらくの間うまくいきました。ただし、今日では、アプリケーションを構築するためのソリューションが大規模になっています。アプリケーション層はすべて、すべてのビジネス層に接触しているようです。再利用は行われていますが、ビルドは遅々として進まず、単一のソリューションに不要なコードが大量に含まれていることは理不尽に思えます。
他の誰かがこの状況に対処しましたか? 後で LLBLGen や NHibernate などの ORM を使用して、データ共有を DAL に落としましたか? それとも、まったく別の何かを思いつきましたか?
Kroonwijkは多くの良い点を示しています。
DALの実装は、（通常は）相互作用する物理データソースに関連付けられていることを忘れないでください。これは、BLとDAL間の相互作用を定義するコントラクトとは異なります。
あなたが説明するアーキテクチャは、再利用性、モジュール化、およびスケーラビリティを提供するベスト プラクティスです。しかし、これらの目標を達成するためにバランスを失う可能性があります。注目すべき点の 1 つは、垂直方向のビジネス ロジック - DAL スタックの分離とサイズの必要性です。モジュールを見て、特定のモジュールが互いに分離されている理由を考えてみてください。それらは、スケーラビリティーのために顧客に個別に導入されますか、それとも個別に販売されますか?
垂直方向に分離する適切な理由が見つからない場合は、いくつかのモジュールをマージして、BL と DAL を共有できるより大きなモジュールに到達できる可能性があります。モジュールの粒度が向上し、オーバーヘッドが削減されます。
また、BL と DAL の間で言及した水平方向の分離も確認できますが、大規模な環境では通常、別の層に展開されるデータ部分からロジックを分離できるという目的を確実に果たします。また、必要なすべての DAL モジュールを BL モジュールで呼び出すことも可能ですが、テーブルが複数のサーバーに分割されている場合、データベースへの複数の接続をサポートする必要があるため、Entity DB マッパーと一緒に使用すると、データベースのスケーリングがより複雑になります。
したがって、私の個人的なアプローチは、BL と DAL の組み合わせの粒度を調べて、それらのいくつかを組み合わせて、多くの優れた機能を失うことなくオーバーヘッドを削減できるかどうかを確認することです。そして、これらすべてのモジュールがあれば、モジュールのグループごとにビルドを並列化できると思います。これは、モジュール化されたアーキテクチャの利点であり、恩恵を受けることができます。なぜだめですか？