It is one of those things I've invested in heavily and later been bitten by its constraints.
Where an ORM really pays for itself is loading/saving nested object graphs that are represented by multiple tables with FK relationships. However, I can usually load/save the same object graph as a document (e.g. JSON-serialized) just as easily and without all the extra ORM tooling.
This is about as complicated as I make database access nowadays. Plus a few more features around performance (run multiple queries at once to avoid round trips, unbuffered reads for large result sets, etc).
But our app is designed to support that. I can save an entity both as a document for viewing/editing purposes, and also save some of the information in a flat table along with a full-text search column for listing/searching.
It is one of those things I've invested in heavily and later been bitten by its constraints.
Where an ORM really pays for itself is loading/saving nested object graphs that are represented by multiple tables with FK relationships. However, I can usually load/save the same object graph as a document (e.g. JSON-serialized) just as easily and without all the extra ORM tooling.
This is about as complicated as I make database access nowadays. Plus a few more features around performance (run multiple queries at once to avoid round trips, unbuffered reads for large result sets, etc).
But our app is designed to support that. I can save an entity both as a document for viewing/editing purposes, and also save some of the information in a flat table along with a full-text search column for listing/searching.
Thanks for sharing your view and the article :)
I like how your tooling is lightweight and simply using sql.