BLLとDAL間のコミュニケーション

Question

ソリューションのセットアップ：

• ダル（クラスライブラリ）
• BLL（クラスライブラリ）
• 共通（クラスライブラリ（いくつかの一般的な機能 - 列挙、ロギング、例外、...））
• Application1（Windowsアプリケーション）
• Application2（Windowsアプリケーション）
• WebApp（Webアプリケーション）
• ...

私が持っているとしましょう お客様 エンティティ、それは次のとおりです。

• SQL Serverのテーブル
• DALで顧客が摂取できる
• BLLの顧客クラス
• すべてのアプリケーションのBll.Customerクラス

コミュニケーションにどのようなオブジェクトとDALを使用する必要がありますか - DataTable また List<Customer> （例えば）？最初に、BLLロジックは顧客オブジェクトをDatatableに変換し、DALに送信する必要があります。 SECODの場合、DALレイヤーはBLLレイヤーの顧客クラスに注意する必要があります。しかし、元のDLLはdalを参照し、反対ではありません...

すべてのクラスを別のアセンブリに配置する必要があります。これは、他のすべてのクラス（一般、BusinessObjectsなど）が参照する必要がありますか？この場合、すべてのプロジェクトで顧客クラスを使用できます。

私が知っているとき、私がDalとBLLを分離することさえわざわざする必要があります。この場合、それらを1つのプロジェクトに統合できます。

PS-私はデータテイタブルについて読んでいます、そして、多くの人々は私たちがそれらをまったく使うべきではないと言います。より良いオプションは何ですか？多分それは私がいくつかのORMマッピングツールを学ぶ時です:)

Answer 1

私の意見では、別のレイヤー（分離DLL）が必要です。 「ドメイン」のように、顧客のようなすべてのエンティティをどこに維持しますか。次に、このアセンブリに階層にすべてのより高いレベル（DAL、BLL、UIなど）を単に含めるだけです。

サンプルアーキテクチャは次のようになります。

（データベース）<-> dal <-> bl <-> ui

また、すべてのレベルでは、「ドメイン」レイヤーにアクセスできます。 DALはリストではなくリストを返す必要があります。開発プロセスの一部では、nhibernateのようなOMRで使用することをお勧めします。おそらくリストも返されます。

Answer 2

アプリケーションドメインを十分に知らずに、この一般的な質問に答えるのは難しいです。将来の変更がどこにあるのかを考えて、柔軟性が必要な場所から把握しようとすることから始めます。

私の次の考えは単なる提案です。それらを自由に検討し、あなたが無関係だと感じるものを変更/無視してください。

DALをBLLから分離することは、ほとんど常に良い考えです。データスキームは、アプリケーションの残りの部分からカプセル化され、非表示にする必要があるものの1つであるため、DALに隠されているデータテーブル、データセット、ORM、またはその他のソリューションを残してください。 BLL（およびその上のレイヤー）は、単純なデータ型（単純なクラスを意味する）を使用する必要があります。参照がなく、どこでも使用できるモデルクラスライブラリにこれらのクラスを配置することをお勧めします。

レイヤーが少し多すぎるような気がします... BLLには顧客クラスが本当に必要ですか、アプリケーションレイヤーには別のクラスが必要ですか？そうである可能性がありますが、私は確かに、それを二度考えてみます。

私の最近のプロジェクトの1つ（毎日200Kユニークな訪問者を抱える気象Webサイト）での私の経験から、Link2SQLをデータアクセス（ほとんど読み取り専用データ）に使用し、ASP.NET MVCアプリケーション全体で簡単なデータクラスを使用しました（もちろん、モデル/ビューモデルの一部）。それは非常にスムーズに機能し、他のレイヤーを分解することなくデータスキームを簡単に変更できます。

データテーブルに関する最後の質問については、これらのオブジェクトを使用することに決めた場合（私は反対票を投じます）、DALだけに属します。その特定のクラスに結合を作成するため、他の層にさらされるべきではありません。明日MSがはるかに良いクラスに発明したらどうなりますか？プロジェクト全体にデータテイティバル、その方法、プロパティに関する数十億の参照があるため、切り替えますか？ Dalを変更してNewawsomedatatableクラスで作業するだけでいいでしょう。また、アプリの残りの部分は至福の無知です。

それが助けてくれることを願っています:)

Answer 3

以下のパターンは、後で別の永続戦略にアップグレードできるため、次のパターンを使用します。

UI/Consumer  <--- (view models) --> BLL <--- Models ----> DAL/Persistence

ここでは、ビューモデルはBLLの外側で消費され、モデルはBLL/DALレイヤー全体で通信されます。

あなたの場合、モデルはDALが使用するものなら何でもあります - たとえば、おそらくORMエンティティなどのDatatables。 BLLは、モデルモデルとビューモデルをマッピングする責任があります。

独自のアセンブリにタイプを保持することについて - はい、モデルを表示し、一貫性を維持するために、モデルもそうです。

モデルとビューモデルを個別に保持すると、BLL以外の持続戦略の漏れが漏れ、したがって、将来の設計の変更が永続性の変更を可能にします。

この分離の利点の1つは、異なるビューモデル消費者が同じ永続性モデル/エンティティの異なるビューモデルを持つことができることです。いくつかは小さく、属性がほとんどなく、その他の機能が豊富なものもあります。また、ビューモデルを異なる時間に返すことができ、データのマージ戦略を決定できるため、オフライン/切断された機能を導入することもできます。これにより、永続的なエンティティ（例えば、形状を成長させて変化させるテーブル）も可能になります。これは.NETの実装のように見えるので AutomApper 箱から出して多くの機能を提供します

もちろん、これはあなたのアプリにとってはるかに過剰になるかもしれませんが、私はまだすべてのBLL消費者に表示モデルのみを伝えるだけのBLLマッピングを維持しています。これにより、十分なデカップリングが得られるはずです。

Answer 4

ドメインエンティティをDALに押し込むことは、鎖骨の依存関係を削除するが、意図と一致しない可能性のあるオプションです。ただし、これは前代未聞ではありません。たとえば、linq-to-sqlのgneratedエンティティはDALに住んでいます。

別のオプション：

• それらを共通に入れます 低い アセンブリ（しかし、それはあなたのBLをかなり空にするかもしれません）
• IOCを使用して、bl / dal間の参照を削除 /逆転させる

ここには単一の正しい答えはありません。

re datatable;個人的には同意します - 私はファンではありません;）しかし、それらはうまくいき、合理的に使用できます。しかし、私の場合 持っていました それらを使用するために、私はそれらを実装の詳細としてDALに保持し、その上にそれらを公開しません。