Home > .NET > Is POCO the right choice when working with entity framework?

Is POCO the right choice when working with entity framework?

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

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: