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