EF4、Linq2SQL、または他のデータマッピング技術でPOCOをサポートすることが非常に重要なのはなぜですか？ OOの意味でのPOCOのコンセプトを理解していますが、ORMの場合は何かがありませんか？EF4、nHiberateに関してPOCOの良い点は何ですか？
編集：私はちょうどORMののコンテキストでPOCOの私の個人的な定義を追加している： 、生成された増補または注釈されたクラスとは対照的に、それは開発者によって手作業でコーディングされているクラスでありますORMマッピングツール（Visual StudioのEF4デザイナーなど）を使用します。
私が間違っている場合は私を修正してください。
"POCO"は、エンティティオブジェクトに不必要な、または直観に反しない制約を設定しないことを意味します。コードジェネレータを使用する必要はなく、フレームワークが提供する基本クラスを拡張する必要はなく、広範囲にアノテーションを付けたり、ほとんどの場合、クラスが常にメモリ内に格納されていた場合とは異なるコードを記述します。これにより、モデルクラスの外部にデータを保持することが懸念され、コグニティブオーバーヘッドが削減されます。
NHibernateまたはEFコードからのPOCO定義をまず比較します。Visual StudioがコードファーストなしでEF用に生成するコードでまず読んで維持することをお勧めします。 （例えば、新しいコードベースの周り突っついた場合。）
通常、特定のORMテクノロジにコードを依存させたくありません。 POCOは依存性を最小限に抑えます。これは、デカップリングの一般原則の1つの化身です。
Entity Frameworkのは、データ クラス自体に変更を加えることなく、データモデルと一緒に をカスタムデータクラスを使用することができます。
これは、既存のドメインオブジェクトなどの「プレーンな」CLRオブジェクト（POCO）をデータモデルで使用できることを意味します。データモデルで定義されたエンティティにマップされるこれらのPOCOデータクラスは、エンティティデータモデルツールによって生成されるエンティティタイプと同じクエリ、挿入、更新、および削除のビヘイビアのほとんどをサポートします。
EFがPOCOをサポートしていると言うのは本当ですか？ – Brendan
はい、エンティティフレームワークは、 "コードファースト"インカネーションを使用する場合、POCOをサポートします。 – StriplingWarrior
@StriplingWarrior Entity Frameworkは、現在のコードが最初にリリースされる前のPOCOをサポートしていました。私は、POCOに関する限り、最初のEFモデルではなく、EFコードを最初から使用することによる利益の大部分を得られないと言っています。どちらも同じように実行可能です。しかし、あなたがRADにいるならば、純粋なPOCOを忘れてください...彼らはEFで多くの追加作業と忍耐を必要とします。 – Brett
良い点。デカップリング/メンテナンス可能な方法とクイック/コード生成の方法の間にトレードオフがありますか？ – Brendan
EF-CFでは、一般的にいくつかの妥当な規則に従うことが期待されているため、「自動」で動作します。物事をより詳細に制御する必要がある場合は、これらの規則を無効にするために正しい注釈を検討する必要があります。コード生成を使用するときは、ビジュアルデザイナーと作業しています。プロパティパネルでは、ドキュメンテーションを習得しなくてはならず、COSにもはや混乱しないように再現する必要はありません。 。 – millimoose