WebFormsでEntity Frameworkを使用する適切な抽象概念は何ですか

Question

私は自分のソリューションを設計する良い方法を見つけようとしています。私は以下のテクノロジ、Asp.Net Webforms、およびEntity Framework 4.1を使用する予定であることを知っています。私のEFモデルは、既存のデータベースに基づいています。私はコンテキストとエンティティを構築するためにEF DbContextジェネレータを使用する予定です。そして、これは私のために物事が少しトリッキーになるポイントです。

私はDALからビジネスロジックを分離することを可能にし、より良いテスト容易性を提供し、懸念を適切に分離したいと考えています。現在私のソリューションにはWeb、Core、Dataという3つのプロジェクトがあります。私は依存関係をウェブにすることを望みます - >コア< - ウェブとデータの間に依存関係のないデータ。これは、データ（私のedmxがある場所）ではなく、コアに実際に存在するエンティティを必要とします。現在、私の考えは、Entities.ttファイルをCoreに移動し、InputFileをData内のedmxを指し示すように変更して、Coreのエンティティを生成することです。しかし、私はContextをどうすればいいのか分かりません。それはEFに大きく依存しているので、単にそれをコアに移したいだけではありません。 IEntities.Context.ttを作成し、Coreにドロップすることを考えました。インターフェイスがDbSetsとDbContextを作成しない場合、私の心配は機能の損失です。

2つの考えは、1）CoreでSystem.Data.Entityを参照し、2）DbSetを使用せず、ICollection（またはそのような汎用コンテナ）と置き換えてラップしますDbContextを自分のインターフェイスのオブジェクトとして使用します。

洞察力は非常に高く評価されます。ありがとうございました。

Answer 1

は、あなたが使用できるさまざまなパターンがたくさんありますが、二人はすぐに頭に浮かぶ：

1）は、ビジネス/サービス層を追加 - あなたのデータ層とプレゼンテーション層との間に、この意志抽象的な。これは私が最も頻繁に取るアプローチです - AutoMapperとDependency Injection（私はNinjectが好きです）を使って、猿の作業をより簡単にします。ビジネス層では、データベースオブジェクトの独自のバージョン（推奨されません）またはビジネスモデルに関連するオブジェクト（より堅牢なアプローチ）のいずれかが公開されます。

2）Inversion of Controlパターンを使用する - 現時点では非常に人気がありますが、実際のシナリオではまだbashを使用していません。明らかにTDD/mockingなどには非常に優れています。基本的には、データレイヤーがビジネスレイヤーに依存するのではなく、ビジネスレイヤーに依存するということです。

FYI - 私の "コア"アセンブリまたは "共通"アセンブリは、ビジネス層やデータ層について何も知らず、単にプラットフォームにとらわれないヘルパーと共通クラスを提供します。たとえば、共通のMVC機能を作成する場合は、代わりにCompany.MVC.Coreアセンブリ。

Answer 2

ソリューションが完全にグリーンフィールドの場合、エンティティフレームワークでコードの第1のアプローチを使用したいと思います（恥知らずのプラグインを許していますが、http://www.terric.co.uk/code-first-entity-framework-and-sql-migrations/については私のブログにチュートリアルを入れました）。私は.edmxを生成するときに私が得ることができないということを私に与えるコントロールが好きです。次のフォルダで構成ドメイン（およびデータ）とのWebUI（名前空間）：

Domain (business layer and data layer assembly) 
    Data (contains my EF data context and Interface to the context) 
    Entities (contains my POCO objects for the context) 

WebUI (presentation layer assembly) 
    Infrastructure (contains my dependency inject initialiser) 

私は決してDI私のエンティティ、代わりに

は、構造上に移動し、私は通常、別のアセンブリに私のプロジェクトの層を分離します私のプレゼンテーション層ではコンクリートを使用しますが、自分のPOCOエンティティの読み書きにADO.Netを使用するドメイン層があるADO.Net（特に従来のアプリケーションの場合）を使用したい/使用する必要があるため、 。このようにして、最終的に私のレガシーアプリケーションでORMを実装する範囲を得ると、私は単に私のドメインのORMバージョンをDIにすることができます。

脚注として、リポジトリパターンをフォローしていた場合は、リポジトリパターンに常にインターフェイスしてリポジトリをDIすることができます。いずれにせよ、あなたのPOCOはソリューション固有のものでなければならないので、基礎となるデータ構造は頻繁には劇的に変化しません。