OdeToCode IC Logo

Are Code Generated POCOs Really POCO?

Monday, July 5, 2010

We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

- from MF’s definition of POJO

The .NET equivalent to a POJO is a POCO (plain old CLR object). POCO is a popular term in .NET development today, having caught the momentum POJOs started generating 10 years ago. This isn’t because .NET is 10 years behind the curve. POJO developers were revolting against the tyranny of oppressive  frameworks during a time when .NET developers were resetting from COM+ to managed code. The  COM+ / WinDNA locomotive was headed in the same tyrannical direction when .NET derailed the train into relative simplicity.

But, I digress.

When I ask developers these days what POCO/POJO means to them I get consistent answers. Stuff like:

  • A POCO doesn’t need to inherit from a framework base class or interface.
  • A POCO isn’t restricted in the data types or relationships it exposes.
  • A POCO is relatively free of infrastructure concerns like persistence.

All these are good rules to define POCO. But why do these rules exist?

Java developers wanted POJOs because they wanted to own the code. The “plain” part is a side effect. They wanted to build object models without the restrictions imposed by a framework. They wanted the freedom to establish hierarchies and relationships. They wanted to pick the data types most suitable for a problem instead of using the data types required by infrastructure. I believe the true spirit of POJO/POCO-ness is only achieved when a developer cares deeply about the POCO classes. Like a gardener who cares about seedlings – the developer wants to grow the classes with a hands-on approach.


Child Tending Broken Baby Seedling by Pink Sherbet Photography.


A generated POCO is an artifact a tool spits out after deriving information from another source -  like a database schema. In most cases this is not a one time generation used to bootstrap a project. Instead, the code generator owns the POCO classes. Code generation dilutes the spirit of POCO.

Perhaps we need a new term: POGO – plain old generated object.

What do you think?