Entity Framework の永続性を無視しないことについて読んでいると、よくPOCO Adapterに出くわします。問題は、それを本番環境で使用する人がいるか、どのように動作し、落とし穴は何かということです。
アプリケーション設計には 2 つの選択肢を検討します。ビジネス ロジックでそのアダプターを使用して POCO を使用し、プレゼンテーション レイヤーでそれらを使用するか、EF エンティティと DTO の間で変換するサービス レイヤーを作成します。(1) EF エンティティ <-> アダプター <-> POCO ビジネスオブジェクト <-> プレゼンテーションまたは (2) EF エンティティ <-> サービス層 <-> DTO <-> プレゼンテーション。最初のアプローチはよりクリーンに見えますが、POCO アダプターがあまり標準的なソリューションではなく、現時点では明らかでないいくつかの欠点が含まれている可能性があることについて、私は少し躊躇しています。
EFPocoAdapter は、Entity Framework 4.0 を支持して廃止されました。ベータ リリースは 1 週間も経たないうちに発表されました。MSDN サブスクライバーであれば、既にベータ 1 をダウンロードできます。
もう EFPocoAdapter を使用する理由はありません。また、EF 4.0 のすべての機能のリストについては、ADO.NET Entity Framework Design Team のブログを読むことをお勧めします。これはすばらしい読み物です。
このブログ投稿もご覧ください: POCO in the Entity Framework: Part 1 - The Experience。
EFPocoAdapter の使用経験に関しては、POCO、遅延読み込み、および n 層シナリオのサポートに満足しています。Entity Framework は、とりわけ T4 テンプレートを提供することによって、これをさらに構築します。これは、私が本当に欠けていると感じたものです (ただし、多くの人は POCO クラスをハンドコーディングすることを好みます)。私が抱えていた他の問題は、循環参照を処理しない JavaScriptSerializer のシリアライザーの問題でしたが、循環参照を処理する DataContractSerializer は、T4 テンプレートより前の自動生成クラスでは不可能だったクラス/メンバー属性を必要とします。
EFPocoAdapter は、コミュニティからフィードバックを得て、EF 4.0 の機能セットを開発するためのステージング プラットフォームのようなものであることが常に意図されていました。端が少し荒いですが、Jaroslaw と数回交換した後ではありますが、なんとか要件を満たすことができました。それとサポートは非常に悲惨でした（フォーラムやスタックオーバーフローにはほとんど人がいませんでした）。
AutoMapperを使用することをお勧めします。次に、必要に応じてEFエンティティ、POCOエンティティ、およびDTOを記述できます。2セットのエンティティは少しオーバーヘッドがあるように見えますが、永続性を知らない必要がある場合は、これがAutoMapperを使用する最も簡単な方法のようです。
このスレッドに、実稼働環境で C# POCO ジェネレーターを使用して生成された POCO モデルで Entity Framework v4 を使用しており (約 6 か月間)、非常にうまく機能していることを追加したいと思います。
ただし、WCF サービスでそれらを使用する場合にはいくつかの問題があります。そのため、WCF を介してそれらを公開することを検討している場合は、賢明な概念実証をまとめて、オブジェクト グラフの複雑さがシリアライゼーション、ステートレスに問題を引き起こすかどうかを確認する価値があるかもしれません。使い方などなど