POCO’s, behavior and Peristance Igorance

I would append another view: POCO states for objects which are not dependent on any framework. The wiki definition of a POJO is much more meaningful to me then the one for POCO:

To paraphrase the wiki definition of the POJO, we can say that POCO object might not be forced to:

I. Extend prespecified class:

public class MyClass : AnyFramework.ObjectBase {...

II. Implement prespecified interfaces

public class MyClass : AnyFramework.IHaveDependency {...

III. Contain prespecified attribute

[AnyFramework.KeyAttribute]
public class MyClass  {...

Given this (almost anything else is allowed) in the meaning of taking care about the object state. Other words, if object will check Business logic, it is correct.

But any POCO object can be used in a framework. Today it is mostly for ORM which is responsible for persistence. All application tiers are working with POCO objects, while data layer is responsible for loading and persisting (CRUD). This is mostly done via Proxies of these POCO objects.

So, POCO could be used as full business object, which can take care about itself (check correctness of collection items, properties…). This makes it different from DTO

Leave a Comment