在阅读 Entity Framework 中缺乏持久性无知时，我经常偶然发现 POCO Adapter .问题是，有没有人在生产中使用它，它是如何进行的，有哪些陷阱？
我考虑了应用程序设计的两种替代方案:在业务逻辑中使用带有该适配器的 POCO，并使表示层使用它们，或者创建一个在 EF 实体和 DTO 之间转换的服务层:
(1)EF实体<->Adapter<->POCO业务对象<->Presentation
或者
(2)EF实体<->服务层<->DTOs<->表示。
第一种方法似乎更干净，但我有点犹豫 POCO Adapter 不是非常标准的解决方案，可能包含一些目前尚不明显的缺点。
最佳答案
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 进行了几次交流之后。那和支持非常惨淡(论坛上很少有人或堆栈溢出)。
关于entity-framework - 有没有人在生产中使用 POCO Adapter for Entity Framework？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/901295/