During DevConnections I veered off the Silverlight track and stumbled into an awesome talk by Chris Sells about EF4. I was really impressed by what is possible now vs 3.5 SP1. At the same time, I’m wondering what benefit there would be in taking a system that is a heavy POCO architecture and inserting EF4 in the mix. Change tracking? LINQ? Anything else I’m not thinking of?
During DevConnections I veered off the Silverlight track and stumbled into an awesome talk
Share
POCO isn’t an architecture. It stands for Plain Old CLR Objects, and is generally used to describe a method of exchanging data between different layers or sections of an application. Years ago that was called DTOs (Data Transfer Objects). The point of POCO being that it has no dependency on any specific data access technology or framework. As a result of being decoupled from the data access layer, you can use them anywhere in the application where you don’t want (or can’t allow) the DAL to bleed into, such as web pages, client applications, and testing (probably the main driving force behind MS supporting POCO entities).
There are plenty of methods to keep your objects ‘clean’ and still have the benefits of EF4. I have a rather large enterprise project which uses POCO entities, change tracking (even over webservices), and LINQ over the entities. All of these features are well documented on the ADO.NET team blog.
tl;dr – If your system is ‘heavy into POCO architecture’, nothing except your DAL will know EF has been introduced.