Does anyone use POCO Adapter for Entity Framework in production?

Question

Reading about the lack of persistence ignorance in Entity Framework I often stumble upon POCO Adapter. The question is, does anyone use it in production, how does it go and what are the pitfalls?

I consider two alternatives for the application design: use POCOs with that adapter in business logic and make the presentation layer use them or create a service layer converting between EF Entities and DTOs: (1) EF entities <-> Adapter <-> POCO business objects <-> Presentation or (2) EF entities <-> Service layer <-> DTOs <-> Presentation. The first approach seems to be more clean, but I'm somewhat hesitating about POCO Adapter is not being very standard solution and may contain some shortcomings not evident right now.

Answer 1

You might want to use AutoMapper. Then you may write EF entities, POCO entities and DTO-s if needed. Two sets of entities seem to be a bit overhead, but when you need to be persistence ignorance, then this seems to be easiest way with AutoMapper.

Introduction to AutoMapper

Answer 2

EFPocoAdapter has been deprecated in favor of Entity Framework 4.0. The beta release was announced less than a week ago and you can already download Beta 1 if you're an MSDN subscriber.

There is no reason to use EFPocoAdapter anymore. I would also encourage you to read the ADO.NET Entity Framework Design Team blog for a list of all the features on EF 4.0, it's an excellent read.

Also have a look at this blog post: POCO in the Entity Framework: Part 1 - The Experience.

As to my experience with EFPocoAdapter, I was/am happy with the support for POCO, lazy loading and n-tier scenarios. Entity Framework builds on this further by providing T4 templates among other things, something which I really felt lacking (though many prefer to hand-code their POCO classes). The other issues I had were serializer issues with JavaScriptSerializer which doesn't handle circular references while DataContractSerializer which does, requires class/member attributes which prior to T4 templates weren't possible with auto-generated classes.

The EFPocoAdapter was always meant to be a sort of staging platform to get feedback from the community and develop the feature-set for EF 4.0. While it is a bit rough around the edges I did manage to fulfil my requirements, albeit after a few exchanges with Jaroslaw. That and support was very bleak (few people on forums or stack overflow).

Answer 3

I'd just like to add to this thread that I've been using the Entity Framework v4 with a POCO model generated using the C# POCO Generator in production (for about six months), and it's been working very well.

There are a few catches when using them with WCF services though, so if you are considering exposing them via WCF it might be worth putting together a sensible proof of concept and see if the complexity of the object graph will pose any problems for serialization, stateless usage etc etc.