en POCO

Published on Friday, May 16, 2008

Source

en POCO

First of all, let me describe what a POCO is.

"POCO" is a Plain-Old-CLR-Object. This means that it does nothing more than be that encapsulated type implemented by that class. It has SRP and has no other responsibility than that responsibility for which is abstracts. It has no coupling to other assemblies that are outside of it's responsibility, and ignorant of anything else. POCO is the .NET side of POJO (Plain-Old-Java-Objects) on the Java side. POJO was a response to the huge problems that occurred years ago with certain persistence frameworks and a requirement for those classes to know about their own persistence. POCO is really about Persistence Ignorance (PI); but the practice of SRP and SoC, when followed, result in POCO.

My next statement might see obvious to some; but it's kinda the reason for my post: any class that requires dependencies outside its responsibility to be pulled in isn't a POCO, by definition. And this includes attributes.

Enter iPOCO.

So, we've got a term that derives from a Java term (POJO) to specially mean a class that is decoupled from any trappings that aren't part of its behaviour, is completely abstracted and encapsulated.

Prepend an i to the term and you get iPOCO, a term that Microsoft is using as a buzzword for the ability of objects that are used with the Entity Framework (EF) to become presistable with that framework. A object that is persistable with EF must implement 3 interfaces: IEntityWithChangeTracker, IEntityWithKey, IEntityWithRelationships. iPOCO is a way to get those interfaces on your class without you having to manually add and implement them, simply by adding an attribute. (it performs some "magic" at build time–and as far as I can tell, is done post compile).

iPOCO is neither more nor less POCO, this is not POCO, it's the opposite of POCO. Your type is not plain, it's decorated with an attribute. That object is now coupled to that attribute and all that it brings with it.

That's why POJO/POCO were given a name, to make the practice explicit. We're writing object-oriented software, it needs to use the basic features of OO: abstraction and encapsulation.

iPOCO == !POCO, If anything it's Persistence Ignorance Ignorance.

comments powered by Disqus