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.


blog comments powered by Disqus
Next Post
A Discovery in Linq: Lookup  11 Feb 2010
Prior Post
Adding AzMan Operations  03 Feb 2010
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
February 2010