c# - エンティティフレームワークを使用する場合、POCOは正しい選択ですか？

Question

POCO（Plain Old CLR Object）についてしばらく読んでいますが、エンティティフレームワークの自動生成された部分クラスを使用する代わりにPOCO（Plain Old CLR Object）を使用することの本当の付加価値を見つけることができませんか？もう1つ、エンティティフレームワークをプレゼンテーション層から直接使用するのが最善ですか、それともBLLを作成する方がよいでしょうか。

Answer 1

POCOの主な利点は、その仕事をするためにEntity Frameworkについて何も知る必要のないクラス、ライブラリ、またはアセンブリにPOCOを渡すことができることです。

単一責任の原則を覚えておいてください。EFはデータアクセスを処理し、それらの層は処理しないため、DALはEFについて知っている必要がありますが、ドメインはそうではなく、プレゼンテーション層もそうではありません。EFで生成されたクラスオブジェクトをこれらのレイヤーに渡すということは、通常、それらのレイヤーにEFを認識させ、SRPを破壊し、それらのレイヤーを単独で単体テストすることを困難にする必要があることを意味します。

以下のコメントでのアリのさらなる質問に応えて、ここに拡張された説明があります。

より複雑なアプリケーションでは、ロジックを個別の関心事（データアクセス、ビジネスロジック、プレゼンテーション（およびおそらくもっと多く））に分割する必要があります。

エンティティフレームワークはデータアクセスを処理するため、データアクセス層に存在します。ここでは、POCOとEFで生成されたクラスの間にほとんど違いがありません。このレイヤーは既にEntityFrameworkを認識しているため、これは問題ありません。

ただし、データをビジネスロジックレイヤーに渡すこともできます。EFで生成されたクラスを使用してこれを行う場合、EFクラスはEFが特別に提供する多くのものに依存しているため、ビジネスロジックレイヤーはEntityFrameworkについても認識している必要があります。これは、ビジネスロジック層が持つべき分離を削除することです。この分離が必要なのは、偽のデータアクセス層からクラスに既知のデータを注入することでユニットテストを正しく実行できるようにするためです。ビジネスロジック層はEFについて知っています。

単体テストでは、サードパーティライブラリの機能ではなく、レイヤーの機能をテストする必要がありますが、EFを使用すると、多くのEFの機能、またはEFの機能に大きく依存する独自の機能をテストすることになります。これは良くありません、そしてそれはエラーや問題を隠すことができます。

EFで生成されたクラスへのビジネスロジックの依存関係を削除すると、データアクセスレイヤーから好きなだけ離れた場所にレイヤーを移動することもできます。Webサービスの背後に貼り付けることもでき、完全に満足できます。ただし、これはPOCOでのみ実行でき、EFで生成されたクラスでは実行できません。

POCOは、大規模で複雑な多層アプリケーションで実際に機能します。アプリを階層化していない場合は、多くのメリットを享受することはできません。

これはすべて私の意見であり、私は経験のある単なるコーダーです-私はコーディングのロックスターではないので、他のコメント投稿者は私の答えをさらに拡大したいと思うかもしれません...

Answer 2

POCOの本当の利点は、最初にコードを使用し、EF移行を使用できることです。最初にコードを使用しない場合は、デザイナーが生成したクラスを使用できます。

大規模なアプリケーションがある場合は、別のBLLを作成する必要がありますが、アプリケーションが非常に小さい場合は、プレゼンテーション層のEFクラスを直接使用できます。

Answer 3

ORMでPOCOクラスを使用すると、そのコードのテストをより簡単に作成できます。また、モデルオブジェクト（POCOクラス）とデータアクセスコードの間に抽象化レイヤーを設定できるため、必要に応じてデータアクセスコード（たとえば、NHibernateのEF）を交換できます。

私は過去にPOCOモデルを使用しましたが、モデルの変更が頻繁に発生し、EFでデフォルトで使用されるモノリシックファイルモデルが適切に拡張されない大企業プロジェクトや開発者の大規模なチームに役立つと言えます。 。小規模なプロジェクトや迅速なアプリケーション開発でのメリットはわかりにくいです。

TLDRバージョン：最初にPOCOとコードの利点を自問している場合、それらを使用しても何も得られない可能性があります。