2009-05-27 11 views
30

レイヤードアーキテクチャを使用するASP.NETアプリケーションがあります。プレゼンテーション層、ビジネスロジック層、データアクセス層。レイヤードアーキテクチャのASP.NETとEntity Framework - ORMのみのEntity Frameworkを使用

ビジネス層はデータアクセスレイヤーの実装方法を知りたくないので、エンティティをEntityDataSourceなどのデータコントロールに直接バインドするつもりはありません。 (したがって、リポジトリパターンのシナリオ)

私は、クラスを生成するためのORMツールとしてENTITYフレームワークを使用することをちょっと見ています。私はこれを行う方法を知っています。私が明確でないものは

  1. ビジネスロジック層がエンティティフレームワークによって直接作成される部分クラスを扱うように、これらのクラスをアプリケーションに伝播することをお勧めしますか? (たとえば、私は顧客テーブルをsqlに持っていれば、エンティティfwは自分のアプリケーションのすべてのレイヤーで直接使用される可能性のある顧客クラスを作成するでしょう)
  2. BLLが複数の異なるエンティティクラス1つの取引として扱いたいと考えています

答えて

9
  1. 実用的な場合:はい!ダブルマッピング作業とダブルマッピングによって生成される潜在的なエラーを回避します。 (二重マッピングによって私はDB - > ORMとORM - >ビジネスロジックを意味する)。
  2. TransactionScopeを使用してください。ネストされたトランザクションを心配することなくトランザクションを実行する最善の方法です。
  3. エンティティフレームワークと
0

ていないが、私はサービス/ BLLでのTransactionScopeのコンテキスト内にラップ(データアクセスアプリケーションブロック3.1を使用して)データアクセス層に別々に実行されている2つのインサートのストアドプロシージャでサンプルを作成しようとしました、うまく行かなかった。 1つの挿入が成功し、もう1つが失敗し、データがコミットされました。

これはあなた自身で成功しましたか?

2

マッパークラスを使用し、EFだけをデータアクセスとして使用し、DAL内で生成されたEFクラスを使用し、マッパーを介してこれらのDALオブジェクトをBLLのオブジェクトにマッピングすることもできます。それは私たちのために正常に動作します。

1

新しいEF4では、POCOクラスを使用することもできるため、レイヤー間でエンティティをマッピングする余分な負荷を取り除くことができます。アプリケーションでは、EF4を使用して、ビューモデル以外のアプリケーション全体でビジネス・エンティティを使用しました。パフォーマンスが大幅に向上しました。

0

生成されたPOCOクラスを使用しても、他のopsが示唆しているように、エンティティフレームワークに対する特定の依存関係、つまりDbContext/ObjectContextに送信するクエリを維持する必要があります。したがって、クエリをリポジトリにカプセル化することを検討する必要があります。