5 ms·
>The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. I am saying this transformation st
by fckgnad 4y ago
>The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as.
I am saying this transformation step is pointless. It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go.
You don't need the object abstraction. SQL is already a high level abstraction. Tables and foreign keys already cover everything you need including the relations.
You are converting tables to objects. One high level abstraction to another. It's like translating English to Chinese to explain something to someone who is already bilingual.
Here's another way to put it:
The models already exist in the database. Why build a repetitive model in the application language? It's a cosmetic thing because people don't want to deal with string manipulation. Overall most of your logic and abstractions lives in the strings you pass to the database. There should be minimal structure and logic for database queries outside of strings in the application code.
- randomdata 4y ago> It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. I'm not sure object oriented programming ever really caught on. The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". > SQL is already a high level abstraction. SQL is a high level query abstraction, but we're talking about the data model. Again, a relation is nothing more than a set of tuples[1]. That is a very primitive data abstraction. Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures? > The models already exist in the database. Why build a repetitive model in the application language? Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code. > It's a cosmetic thing because people don't want to deal with string manipulation. String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory. [1] If we are being pedantic, SQL actually deviates from the relational model by not staying completely true to sets. But the terminology has stuck regardless.
- acdha 4y ago> The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". What about Java, C#, and Python? The first two have been go-to at many businesses since the turn of the century. If C++ isn’t mainstream it’s because in no small part people picked those instead.
- randomdata 4y agoI expect Java was once confused as being object oriented because James Gosling came from a Smalltalk background and Patrick Naughton from an Objective-C background and as a result Java takes a lot of inspiration from those two languages. But it misses the part that provides orientation. Java's object model is much closer to C++'s in that regard, and C++ definitely isn't object oriented. The coiner of the term even once literally said so. Not sure why you think C# and Python are object oriented? They have what could be considered objects, but where does the orienting come into play?
- fckgnad 4y agoThe distinction between smalltalk and other oop languages is not relevant. The majority of the human race thinks of java as oop and is referring to such languages when communicating. Please do the same.
- acdha 4y agoBecause that’s how their creators describe them. C# started as COOL, as in “C-like Object Oriented Language”. Python incorporates that term in descriptions from the 90s and see e.g. http://python-history.blogspot.com/2009/01/introduction-and-overview.html http://python-history.blogspot.com/2009/01/introduction-and-... Both incorporate other paradigms like every other popular language but that doesn’t negate the huge influence OOP had on several generations of languages. If you’re on some weird purity bent where you insist mainstream usage is wrong, well, I can’t stop you but I’ve never seen that result in something insightful or educational.