エンティティフレームワーククラスとPOCO

Question

私は建築設計に関する意見の一般的な違いがあります。また、stackoverflowを使用して意見を求めるべきではありませんが、以下に説明する両方のアプローチの賛否両論をお願いしたいと思います。

詳細： - C＃アプリケーション - SQL Serverデータベース - Entity Frameworkの を使用して - そして、我々は

シナリオ1を我々は情報を保存するために使用しようとしているオブジェクトかを決定し、アプリケーション全体のすべてを使用する必要があります： Entity Frameworkエンティティを使用して、すべてを渡しますたとえば、オブジェクトを使用してすべての情報を格納する必要がある場合など、BLに渡すと、最終的にWepApiはこのエンティティを取得して値を返します。 DTOもPOCOもありません。

データベーススキーマが変更された場合、エンティティが更新され、使用されるすべてのクラスが変更されます。

シナリオ2： アプリケーションで必要なすべての情報を保持するために、DTOと呼ぶか、POCOと呼ぶ中間クラスを作成します。エンティティに格納された情報をPOCOに取り込む中間段階がありますが、すべてのEFコードをすべてのレイヤーではなくデータアクセス内に保持しています。

それぞれの賛否両論は何ですか？

Answer 1

中間クラス、つまりEFエンティティの代わりにPOCOを使用します。

私が直接EFエンティティを使用するように参照のみの利点は、書き込みに少ないコードであるということです...

メリット代わりPOCOを使用する：

あなたは、あなたのアプリケーションが実際に

を必要とするデータを公開

基本的には、GetUsersビジネス方法があるとします。あなただけの（つまり、あなたが自分のID、名前、例えば最初の名前が必要です）グリッドを移入するユーザーのリストをしたい場合は、あなただけのようなもの書くことができます：

public IEnumerable<SimpleUser> GetUsers() 
{ 
    return this.DbContext 
     .Users 
     .Select(z => new SimpleUser 
     { 
      ID = z.ID, 
      Name = z.Name, 
      FirstName = z.FirstName 
     }) 
     .ToList(); 
} 

をそれは何を実際にあなたの方法は明らか結晶であります戻る。 今の代わりに想像し、それは

それは本当に消費者の仕事を簡素化...あなたは（そのようPasswordフィールドとして）公開したくないすべてのナビゲーションプロパティと内部のもので、完全なUserエンティティを返して、あなたのサービス

さらにビジネス方法のようにCreateの方が明らかです。

public class User 
{ 
    public long ID { get; set; } 
    public string Name { get; set; } 
    public string FirstName { get; set; } 
    public string Password { get; set; } 
    public bool IsDeleted { get; set; } 
    public bool IsActive { get; set; } 
    public virtual ICollection<Profile> Profiles { get; set; } 
    public virtual ICollection<UserEvent> Events { get; set; } 
} 

：あなたは確かに想像

...とても性質が実際に必要とされるものをを知るために、あなたのサービスの消費者のために複雑になる、パラメータとしてUserエンティティを使用するには、次のエンティティをしたくありません

void Create(User entity);メソッドを使用するためにはどのプロパティが必要ですか？

• ID：知らん、多分それが生成されます多分それは
ではありません
• 名/姓：だけでなく、それらは
• パスワードを設定する必要があります。プレーンテキストのパスワード、ハッシュ化されたバージョンということですか？それは何ですか？
• IsDeleted/IsActive：ユーザーを自分でアクティブにする必要がありますか？ビジネス方法で行われますか？
• プロファイル：hum ...どのようにユーザーにプロファイルに影響を及ぼしますか？
• イベント：地獄は？

それははい、私は複数の理由のためにこの機能を憎むない使用遅延ロード

にあなたを強制します。それらの一部は：

• 非常に使いにくいです。開発者が遅延ロードを適切に使用する方法を知らなかったため、何千ものSQLリクエストを生成するコードが多すぎることがわかりました。
• 例外を管理するのは非常に難しいです。 SQLリクエストをいつでも実行できるようにすることで（遅延ロード時）、データベース例外を管理する役割を上位層、つまりビジネス層またはアプリケーションに委任します。悪い習慣。

POCOを使用すると、自分のエンティティを熱心に読み込むように強制できます。 AutoMapper

AutoMapperについて

あなたは自動的にその逆POCOSと副らにエンティティを変換することができるツールです。私はそれも好きではない。 https://stackoverflow.com/a/32459232/870604

Answer 2

私は反対の質問があります：どうしてですか？？

任意のMVCアプリケーションを検討してください。モデルとコントローラレイヤでは、通常、EFオブジェクトを使用します。コードファーストを使用して定義した場合、アプリケーションでの使用方法は基本的にはとなっており、アプリケーションに必要な変更を正確に保存するようにパーシスタンスレイヤーを設計しました。

これらのオブジェクトをViewレイヤーに表示することを検討してください。ビューには、オブジェクト、または作業オブジェクトの集約が反映されている場合と反映されていない場合があります。これはしばしば、ビューに必要なものをキャプチャするPOCOS/DTOにつながります。もう1つのシナリオは、Webサービスにオブジェクトを公開する場合です。多くのフレームワークでは、pocoクラスを簡単にシリアライズできます。その場合、通常は、1）EFクラスに注釈を付けるか、2）DTOを作成する必要があります。

また、POCOSを使用したり、コンテキストを閉じると、EFクラスに遅延ロードが発生する可能性があります。