> I NEVER want to go back to ORM
Except that you just invented your own ORM.
Think about it: you are encapsulating SQL data into classes, in other words, mapping relational data to objects.
That's an ORM.
Except that you just invented your own ORM.
Think about it: you are encapsulating SQL data into classes, in other words, mapping relational data to objects.
That's an ORM.
That's a rather nonstandard usage.
If you are taking data out of a relational database and mapping it into objects, you are implementing an ORM.
Seems like I'm sticking to the exact definition of an ORM, aren't I?
No, ORM is a particular approach to doing that; the query abstraction approach described upthread is closer to the DAO pattern, to which ORM is an alternative. People were using RDBMSs to provide a persistence layer for OO programs before ORM was a thing, but as you have broadened the term any use of an RDBMS to store/retrieve data used in an OO program would be "ORM".
Object-relational mapping (ORM, O/RM, and O/R mapping)
in computer science is a programming technique for
converting data between incompatible type systems
in object-oriented programming languages.Spearfishing is a technique for catching fish, but not every technique for catching fish is spearfishing.
ORM frameworks usually allow you to drop down to SQL. But then you're stuck in that terrible world of depending on poorly-documented and soon-to-be-deprecated (or already deprecated) internals. Which are pretty much guaranteed to not fit what you really need anyway. Then you have to bridge your hack objects with the "proper" ORM objects. Your crufty hack objects will probably never be seen as first-class citizens in ORM land, forever banished to edge case hell.