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

The main reason is that a lot of people like to develop their model with a specific mindset: like DDD for instance. They might want to use a specific pattern (like Spec or State) for things like statuses (instead of enums) - or you might want to use a Factory for instantiation.

OO breaks when you try to use Tables as Objects when things get more complex. Simple sites work OK - but when you get to big big things, it gets ugly.

So - as always - it depends what you think your project will turn into.

Answer 2

My experience is that when you start writting some complex queries .Include method is worthless and you will find yourself either:

a) Writting a lot of queries to get the data you want or b) abusing of annonymous types to load the data in a single query and then writting a lot of code just to pass that data to your entities.

POCOs are the way to go, IMHO.

Answer 3

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.