エンティティフレームワークからエンティティオブジェクトを分離する方法は？

、私がフォローしたいデータアクセス層にアクセスできません。同じアーキテクチャ。

ビジネスサービスここでは、レイヤ
- ビジネスロジック。
- "エンティティ" と "データ・アクセス・レイヤー" ここで行った
データアクセス層
- SQL操作にアクセスできます。
- ここでEntity Frameworkの（.edmx）
エンティティレイヤ
- 私はここでEntity Frameworkのクラス（EntityObject）を使用します。したがって、すべてのDTOを書き換える必要はありませんが、これでCRUDを実行しないでください。ObjectContext/Dbcontextを含めるべきではありません
プレゼンテーション層
- ビジネスとエンティティにアクセスできます
- データアクセス層（Entity Frameworkの）
- ビューにアクセスすることはできません

'dbContext.SaveChanges（）'を呼び出すとCRUDが発生します。これがデータアクセスレイヤーでのみ行われる限り、あなたは良いことが必要です。 –

@GeorgPatscheider私は文脈がそこにあるべきではないことを意味します.. –

しかし、文脈はあなたがSQL操作を実行することを可能にします。私たちのアーキテクチャでは、ビジネス層とデータアクセス層（ビジネスロジックはDbContextとエンティティと直接連携します）を組み合わせました。 –

私が出したいものはほとんどありません：

データアクセス層 - edmxに依存する場合、アプリケーションは密接に結合されてEntity Frameworkを使用します。可能であれば、どのORMが下に実装されているかを知らなくても、DALが抽象化としてEntityレイヤーと会話するようにデザインを作成します（インターフェイスベースのデザイン）。将来的には、比較的少ない労力で他のORMを導入することができます。
ビジネスサービスレイヤがエンティティレイヤの参照を持つ必要があるのはなぜですか。それは理想的には参照を持っていて、DALだけにアクセスしなければならない。
プレゼンテーションレイヤーと同じコメントです。

2016-08-12 09:45:01

私はPresenterでオブジェクト内のエンティティのデータにアクセスしています.->ビジネスに送る - >ビジネスは、エンティティをDALに転送する複数のビジネスロジックを行います - > DALはCRUDを行います.. –

エンティティはEFクラスを意味します。プレゼンターとビジネスはEFクラスに理想的にアクセスできないものとします。少なくともプレゼンターはそれを持っていないはずです。 –

データアクセス層の実装は、それが独自の実装の詳細なので、EFについて知っていなければなりません（MUST）。データ層からEFを抽象化することはまったく意味がありません。レイヤーの名前：データアクセスレイヤーを確認します。 –

答えて