.NET Programming – Understanding POCO Classes

design-patternsnetobject-oriented

I was having a think tonight while pondering over some application I need to change and it got me thinking. Entity Framework Entities are POCO (Plain old CLR Objects) and models used in ASP.NET MVC are usually also POCO. This basically means just properties, no methods.

Now OO programming normally allows an object to encapsulate its functionality, which includes its properties as well as its methods, this allows for polymorphism to happen. With the rise of POCO classes being used, design patterns like generic repositories have become more popular. When in the past my objects would have had their own CRUD operations, I now have them on a repository.

Is this just an evolution in OO where CRUD operations are removed from the objects to allow them to be decoupled or maybe CRUD operations shouldn't have been at object level in the past and I was in the wrong? heck, maybe both are perfectly legit and always have been. Its just an observation that got me thinking, so figured I would seek other opinions.

Best Answer

As Wyatt said, POCO and POJO in no way implies no methods. I think that stems from not knowing what non-POCO and non-POJO is.

First versions of ORM technologies weren't POCO and POJO simply because it required the entities to inherit some base class from the framework itself. In case of Java, Entity Beans .In case of Entity Framework, POCO wasn't possible in very first version and each entity was required to inherit Entity base class.

This requirement created dependence of your data model on the persistence technology, which makes lots of things hard or impossible. Things like unit testing the model requires mocking the bean/entity framework which proved to be practically impossible. You also cannot use the model with different persistence technology or you cannot use the model in different context, like in mobile environment.

So your assumption that POCO is about non-existence of methods is wrong. POCO is about being able to use the model in separation from it's persistence technology.

What you are talking about is probably closes to Anemic Domain Model vs proper domain model.

Related Topic