Improving on POCO: The ORM Problem

One area where improving on POCO has potential to impact greatly is that of database persistence - the domain of the object relation mapper, or ORM.

On one hand, the greater semantics of our objects makes them a richer source of information, allowing the ORM to act in a more intelligent way.

For example, the built in dirty-tracking of our properties will allow the ORM to avoid updating columns that haven’t changed. Similar features built into our collections and associations will allow the ORM to generate minimal SQL, sufficient to make the required changes and no more, ensuring (for example) that related instances that haven’t changed won’t be touched.

On the other hand, without additional effort, many of the current generation of ORMs won’t know how to properly hydrate instances when they are loaded from the database. Instead of simply setting the Name property to the value of the column, the ORM somehow needs to know that Name is a property container, and that the nested Value property should be assigned.

To me, this is one of the biggest challenges when trying to improve on POCO objects, as it seems the benefits I gain in my own code from the added semantics are lost when trying to leverage other libraries.