Question

I’ve been reading about POCO (Plain Old CLR Object) for a while but still can’t find the real added value of using it instead of using the auto generated partial classes of the entity framework?
One more thing is it best to use my entity framework directly from the presentation layer or creating a BLL will be better?

Answer 1

The main benefit of a POCO is that you can pass it to a class, library or assembly that doesn’t need to know anything about Entity Framework to do its job.

Remember the Single Responsibility Principle – your DAL should know about EF, but your Domain should not, and neither should your presentation layer, because EF deals with data access and those layers do not. Passing EF generated class objects up to those layers generally means you need to make those layers aware of EF, breaking the SRP and making it harder to unit test those layers in isolation.

In response to Ali’s further query in the comments below, here is an expanded explanation.

In more complex applications, you will want to split the logic up into separate concerns – data access, business logic, presentation (and perhaps a lot more).

As entity framework deals with data access, it resides in the data access layer – here, you will see little difference between POCOs and EF generated classes. This is fine, because this layer already knows about Entity Framework.

However, you may want to pass data up to the business logic layer – if you do this with EF generated classes, then your business logic layer must also know about Entity Framework because the EF classes rely on a lot of things EF provides specially. What this does is remove the isolation that your business logic layer should have – you need this isolation so you can unit test it correctly by injecting known data into the class from a fake data access layer, which is incredibly hard to do if you let the business logic layer know about EF.

With unit testing, you should be testing the layers functionality, not the functionality of third party libraries – but with EF you end up testing a lot of EF’s functionality, or your own functionality which relies very heavily on that of EF’s. This isn’t good, and it can mask errors or issues.

Removing the business logics dependency on EF generated classes also allows you to move the layer to as remote a location as you like from the data access layer – you can even stick it behind a web service and it would be completely happy. But you can only do this with POCOs, you cannot do this with EF generated classes.

POCO’s really come into their own in large, complex multi layered applications – if you aren’t layering your app, then you won’t see a whole load of benefits imho.

All of this is my opinion, and I’m just a coder with experience – I’m not a coding rockstar, so some other commenters may like to further expand my answers…