7

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

  • DAL (クラス ライブラリ)
  • BLL (クラス ライブラリ)
  • 共通 (クラス ライブラリ (いくつかの共通機能 - 列挙型、ロギング、例外など))
  • アプリケーション 1 (Windows アプリケーション)
  • アプリケーション 2 (Windows アプリケーション)
  • WebApp (Web アプリケーション)
  • ...

次のCustomerエンティティがあるとします。

  • SQL サーバーのテーブル
  • DAL の CustomerDataTable
  • BLL の Customer クラス
  • すべてのアプリケーションの BLL.Customer クラス

BLL と DAL はどのような種類のオブジェクトを通信に使用する必要がありますDataTableかList<Customer>? (たとえば)? 最初のケースでは、BLL ロジックは Customer オブジェクトを DataTable に変換し、それを DAL に送信する必要があります。2 番目のケースでは、DAL レイヤーは、BLL レイヤーにある Customer クラスを認識する必要があります。しかし、もともとDLLはDALを参照しており、反対ではありません...

すべてのクラスを、他のすべて (Common、BusinessObjects など) から参照される個別のアセンブリに配置する必要がありますか? この場合、すべてのプロジェクトで Customer クラスを使用できます。

1 つの BLL だけが DAL を使用することがわかっている場合でも、わざわざ DAL と BLL を分離する必要があります。この場合、それらを 1 つのプロジェクトにマージできます。

PS - 私は DataTables について読んでいますが、多くの人が DataTables をまったく使用すべきではないと言っています。より良いオプションは何ですか? たぶん、ORMマッピングツールを学ぶ時が来ました:)

4

4 に答える 4

9

私の意見では、別のレイヤー (個別の dll) が必要です。「ドメイン」のように、顧客のようなすべてのエンティティをどこに保持しますか。次に、このアセンブリを階層内のすべての上位レベル (DAL、BLL、UI など) に含めるだけです。

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

(データベース) <-> DAL <-> BL <-> UI

すべてのレベルで、「ドメイン」レイヤーにアクセスできます。DAL は DataTable ではなく List を返す必要があります。開発プロセスのある段階で、DAL で使用したい NHibernate のような OMR もおそらくリストを返すでしょう。

于 2010-10-17T09:04:14.780 に答える
4

アプリケーション ドメインを十分に理解していないと、この一般的な質問に答えることは困難です。将来の変更が最も起こりそうな場所を考えることから始め、そこから柔軟性が必要な場所を見つけようとします。

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

ほとんどの場合、DAL を BLL から分離することをお勧めします。データ スキームはカプセル化してアプリケーションの残りの部分から隠す必要があるため、DataTable、DataSet、ORM、またはその他のソリューションを DAL に隠しておきます。BLL (およびその上のレイヤー) は単純なデータ型 (つまり単純なクラス) を使用する必要があります。これらのクラスを、参照がなくどこでも使用できるモデル クラス ライブラリに配置することをお勧めします。

階層化が少し多すぎるように感じます...本当に BLL に Customer クラスが必要で、アプリケーション層に別のクラスが必要ですか? かもしれませんが、私はそれを確認して、もう一度考えます。

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

DataTables に関する最後の質問については、これらのオブジェクトを使用することにした場合 (私は反対票を投じます)、DAL にのみ属します。特定のクラスへの結合が作成されるため、他のレイヤーに公開しないでください。明日、MS がより優れたクラスを発明したらどうなるでしょうか。プロジェクト全体で DataTables、そのメソッド、およびプロパティへの無数の参照があるので、切り替えますか? NewAwsomeDataTable クラスで動作するように DAL を変更するだけで、アプリの残りの部分は幸いなことに無知になります。

お役に立てば幸いです:)

于 2010-10-17T08:39:29.773 に答える
2

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

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

ここで、ビュー モデルは BLL の外部で使用され、モデルは BLL/DAL レイヤー間で通信されます。

あなたの場合、モデルはDALが使用するものなら何でもかまいません-たとえばDataTablesまたは後でおそらくORMエンティティです。BLL は、モデルとビュー モデル間のマッピングを担当します。

独自のアセンブリに型を保持することについては、ビュー モデルの場合、一貫性を維持するために、モデルの場合も同様です。

モデルとビュー モデルを別々に保持することで、永続化戦略が BLL の外部に漏れるのを防ぐことができるため、永続化に対する将来の設計変更が可能になります。

この分離の利点の 1 つは、異なるビュー モデル コンシューマーが同じ永続化モデル/エンティティに対して異なるビュー モデルを持つことができることです。小さくて属性がほとんどないものもあれば、大きくて機能が豊富なものもあります。ビューモデルが異なる時間に返される可能性があるため、オフライン/切断機能を導入して、データマージ戦略を決定することもできます。これにより、エンティティを永続化することもできます (たとえば、テーブルを成長させたり形状を変更したりできます)。これは .net 実装のように見えるので、AutoMapperのようなものはすぐに使える多くの機能を提供します。

もちろん、これはあなたのアプリにとってはやり過ぎかもしれませんが、私はまだ、ビュー モデルをすべての BLL コンシューマーとやり取りするだけの BLL マッピングを維持します。これで十分なデカップリングが得られるはずです。

于 2010-10-17T08:31:32.017 に答える
1

ドメイン エンティティを dal にプッシュすることは、crcular 依存関係を削除するオプションですが、意図と一致しない場合があります。ただし、これは前例のないことではありません。たとえば、LINQ-to-SQL 生成エンティティは DAL に存在します。

その他のオプション：

  • それらを共通の下部アセンブリに入れます (ただし、BL はかなり空のままになる可能性があります)。
  • IOC を使用して BL/DAL 間の参照を削除/反転する

ここに唯一の正解はありません。

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

于 2010-10-17T08:38:33.453 に答える