是否有人在生产中为实体框架使用POCO适配器?

为了支持Entity Framework 4.0,已弃用了EFPOcadapter。这个 beta release 发布时间不到一周,如果您是msdn用户,那么您已经可以下载beta 1了。

没有理由再使用efpocoadapter了。我还建议您阅读ADO.NET实体框架 Design Team blog 对于EF4.0的所有功能列表,这是一个非常好的阅读。

也可以看看这个博客: POCO in the Entity Framework: Part 1 - The Experience .

至于我在efpocoadapter上的经验,我对支持poco、延迟加载和n层场景感到高兴。实体框架通过提供T4模板以及其他一些东西来进一步构建这一点,这是我真正感到缺乏的(尽管许多人更喜欢手工编写他们的POCO类)。我遇到的其他问题是 serializer issues 使用不处理循环引用的JavaScriptSerializer,而使用DataContractSerializer,则需要类/成员属性,而在T4模板之前,这些属性对于自动生成的类是不可能的。

efpocaradapter一直被认为是一种从社区获得反馈并为ef 4.0开发特性集的平台。虽然这是一个有点粗糙的边缘,我确实设法满足我的要求,尽管经过几次与雅罗斯拉夫交流。这一点和支持非常糟糕(很少有人在论坛或堆栈溢出)。

你可能想用 AutoMapper .然后,如果需要,您可以编写EF实体、POCO实体和DTO-S。两组实体似乎有点开销,但当您需要保持无知时,使用automapper这似乎是最简单的方法。

Introduction to AutoMapper

我只想添加到这个线程中,我一直在使用实体框架v4和使用C poco生成器在生产中生成的poco模型(大约六个月),它运行得非常好。

有一个 few catches 但是,在将它们与WCF服务一起使用时,如果您考虑通过WCF公开它们,那么有必要对概念进行合理的证明,并查看对象图的复杂性是否会对序列化、无状态使用等造成任何问题。