What are the pros/cons of returning POCO objects from a Repository rathen than EF Entities?

Question

Following the way Rob does it, I have the classes that are generated by the Linq to SQL wizard, and then a copy of those classes that are POCOs. In my repositories I return these POCOs rather than the Linq to SQL models:

return from c in DataContext.Customer
       where c.ID == id
       select new MyPocoModels.Customer { ID = c.ID, Name = c.Name }

I understand that the benefit of this is that the POCO models can be instantiated easier so this will make my code more testable.

I'm now moving from Linq to SQL over to Entity Framework and I'm about half way through an EF book. It seems there's a lot of goodness I'm going to lose out on by returning POCOs from my repositories rather than the EF entities.

I still haven't really embraced unit testing, so I feel like I'm wasting a lot of time creating these extra POCOs and writing the code to populate them, when all I appear to be gaining is testable code, yet I'm also gonna lose out on a lot of the benefits of the EF by not being able to track my objects.

Does anyone have any advice for a relative newb to all this ORM/Repository stuff?

Anthony

Answer 1

Another reason people don't like the auto-generated objects (in LINQ to SQL for example) is because of their built-in "magic".

Usually the magic is invisible and you never notice it, but when you try to do things like serialize one of those objects and then deserialize it (for example when using web services) its internal connection to the data source is broken and special hacks need to be employed to "put the magic back in".

With POCOs, you don't have to worry about those sorts of things and can get a better separation between your data and service layers. The downside of course is that you have to write lots of boring POCO -> magic object and magic object -> POCO conversion code. But in the end I think it's usually worth it, especially for large or complex projects.