POCO Vs Entity Framework Generated Classes? [close

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

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 ?

Answer 1

Look at following articles:

http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

http://blogs.msdn.com/b/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading.aspx

http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx

Answer 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.

Answer 3

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.

Answer 4

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.