| > The specifics of how you retrieve data is an implementation detail. Correct. > (behind a system dedicated to pulling data). That's the textbook definition of a good ORM. > One could easily argue that you should be able to manually interact with db readers all throughout the codebase, after all, it's an abstraction. It depends on the abstraction they present. SQL throughout the code would be a train wreck. On the other hand, something like: * A stored procedure to have a filtered list of gizmos... * Mapped onto an AJAX or a function call in a data layer... * Being called whenever one needs a filtered list.... is the way to do it. If all you have are tables of simple data, that's exactly what a good ORM would do. |
That's never been how the acronym was defined. The reason you're now trying to define it that way is because the only other alternative is to admit you're wrong.
"what if that subsystem is pulling data from AS400?" -- still an ORM!
"what if that subsystem is pulling data from an INI file?" -- still an ORM!
"what if that subsystem is pulling data from an IOT device? via the MQTT protocol" -- still an ORM!
------
The difference between an ORM and what I'm describing is that the subsystem I'm describing actually abstracts the where and the how, an ORM _is_ an implementation detail. This is why sprinkling ORM code throughout your codebase presents a problem, it's akin to re-implementing the code to pull out of an INI repeatedly instead of putting it behind a function with a single implementation.
Now go away.