What are the advantages of using one over the other ? I know POCO classes are more optimal but are they worth the overkill ? And should we always be using POCO's or is there a time when you should prefer entity framework classes ?
Asked
Active
Viewed 9,131 times
4 Answers
8
The EF default classes all inherit from EF base class, while POCO don't (hence the name). While inheriting from EF base class, the logic behind change tracking is hidden from you and all of the logic is stored inside the context that's holding references to your objects. This is preferred if you're working in a connected state, ie, you have context at the same time you have entities. This is usually the case where you build 'fat' client, so the client and the database are the only two tiers.
On the other hand, if you're working with web services / web forms, the entities you pass around don't have a context and have to track the state themselves - then the POCO is the better option, since they have change tracking object as their property that can be transferred around until you decide to apply the changes to the context and save. One other benefit would be that your clients don't have to be .NET and don't have to have the EF .dll to deserialize your objects.
veljkoz
- 8,384
- 8
- 55
- 91
2
The reason I use POCO is separation of concerns i.e. I don’t want my front end to have to know how my back end works. So if I want to change from Linq To Sql to EF or N Hibernate I don’t have to modify my front end code.
Anthony
- 1,651
- 1
- 17
- 31
2
Use POCO's if you want clean architecture, loose coupling and supreme testability.
If you don't care about those things then don't use them.
Personally to me those are the most important things in any application (especially one that is required to be maintained over a long period of time), therefore i always use POCO's.
With that in mind, POCO's require you implement some kind of change tracking mechanism, which can be tricky. But it's a one-time setup thing, and is worth the effort.
I have this logic in a custom DLL which i share amongst projects - so i don't have to keep doing it again and again.
For more info on why POCO's are important in the general sense (not EF/.NET specific), see my answer here.
-
Why not simply represent your "POCO" with an interface that your EF generated classes can implement? Then your UI (or upper level service) can achieve loose coupling and testability by only working off the interface definitions instead... And there will be no need to write/execute conversion functions. – Reddog Jan 09 '11 at 21:16
-
@Reddog - Well my POCO assembly has no references to `System.Data.Entity`, no reliance on EF. If you use EF generated classes then your class library becomes "tied" to EF. If i want to move to another ORM (or DAL), i can re-use my POCO classes. The same can't be said with EF generated classes. It's not just about loose coupling from *other* projects, it's about loose coupling between the POCO's and Entity Framework itself. It allows a true "domain model". – RPM1984 Jan 09 '11 at 22:15
