阅读有关实体框架中缺乏持久性无知的信息时，我经常偶然发现POCO Adapter。问题是，有没有人在生产中使用它，它是怎么做的，有什么陷阱？
我考虑了应用程序设计的两种替代方案：在业务逻辑中使用带有该适配器的 POCO，并使表示层使用它们或创建在 EF 实体和 DTO 之间转换的服务层： （1）EF实体适配器POCO业务对象Presentation 要么 (2) EF 实体 服务层 DTO 表示。 第一种方法似乎更干净，但我有点犹豫 POCO Adapter 不是非常标准的解决方案，可能包含一些目前不明显的缺点。
【问题讨论】：
标签： entity-framework architecture poco
EFPocoAdapter 已被弃用，取而代之的是 Entity Framework 4.0。 beta release 是在不到一周前发布的，如果您是 MSDN 订阅者，您已经可以下载 Beta 1。
没有理由再使用 EFPocoAdapter。我还鼓励您阅读 ADO.NET Entity Framework Design Team blog 以获取 EF 4.0 上所有功能的列表，这是一本极好的阅读材料。
也可以看看这篇博文：POCO in the Entity Framework: Part 1 - The Experience。
就我使用 EFPocoAdapter 的体验而言，我对 POCO、延迟加载和 n 层场景的支持感到满意。 Entity Framework 通过提供 T4 模板以及其他东西进一步构建了这一点，这是我真正感到缺乏的东西（尽管许多人更喜欢手动编码他们的 POCO 类）。我遇到的其他问题是 serializer issues 使用 JavaScriptSerializer，它不处理循环引用，而 DataContractSerializer 需要类/成员属性，而在 T4 模板之前，自动生成的类是不可能的。
EFPocoAdapter 始终旨在成为一种从社区获得反馈并为 EF 4.0 开发功能集的临时平台。虽然边缘有点粗糙，但我确实设法满足了我的要求，尽管在与 Jaroslaw 进行了几次交流之后。那和支持非常惨淡（论坛上的人很少或堆栈溢出）。
【讨论】：
您可能想使用AutoMapper。然后，如果需要，您可以编写 EF 实体、POCO 实体和 DTO-s。两组实体似乎有点开销，但是当您需要对持久性无知时，这似乎是 AutoMapper 最简单的方法。
【讨论】：
我只想在此线程中添加我一直在使用实体框架 v4 和使用 C# POCO 生成器在生产中生成的 POCO 模型（大约六个月），并且运行良好。
虽然在将它们与 WCF 服务一起使用时有一个 few catches，所以如果您正在考虑通过 WCF 公开它们，可能值得将它们放在一起进行合理的概念证明，看看对象图的复杂性是否会造成任何问题用于序列化、无状态使用等。
【讨论】：