4 ms·

The article leaves out a few weaknesses of ORMs 1. inability to represent arbitrary query results. Results get mapped back into 'domain-objects'. Now you've re

by beders 3y ago

The article leaves out a few weaknesses of ORMs 1. inability to represent arbitrary query results. Results get mapped back into 'domain-objects'. Now you've removed yourself from the extreme expressiveness of the SELECT statement as well as GROUP BY, pivot tables etc. etc. The best you can hope for is domain objects that are only partially initialized with values. 2. lazy loading of attributes - certainly configurable, but if you rely on SELECT statements being generated while you are navigating a 'persistent' object, you will run into unexpected performance issues. To solve those, you then start to eagerly load domain data for certain access patterns. More annotations, more configurations and more ... stuff - where a nice SELECT query would have sufficed to get the data you need. 3. Troubleshooting is a pain. Especially if you rely on dynamically building queries. Have fun getting the actual SQL that was run and then translate back and forth between SQL and the query builder syntax to optimize it - if you can even optimize it. 4. Doesn't treat data as data. First of all data coming from SQL queries is stale the moment it arrives in your objects. Trying to pretend otherwise and having an object graph that pretends to be the living counterpart of the state in your DB is foolishness. 5. No/limited control over writes/updates. The moment you rely on your ORM to create UPDATEs and INSERTS to reflect the state of your object graph back into the DB, good luck with your chosen locking strategy and good luck optimizing those. Pessimistic locking is the best worst you can hope for. Stay away from ORMs (as in Hibernate and its ilk) and treat data as data. Use structs/records.

jbverschoor 3y ago
5x simply not true
- DandyDev 3y ago
  That is a cheap comment. Could you elaborate why you disagree with the comment you respond to?
  - isbvhodnvemrwvn 3y ago
    Not the original responder - hibernate has had projections to solve #1 for ages, the rest are on point IMO.
  - jbverschoor 3y ago
    > 1. inability to represent arbitrary query results.... You can either use any SQL or HQL with hibernate. > 2. lazy loading of attributes - certainly configurable, but if you rely on SELECT statements being generated while you are navigating a 'persistent' object, you will run into unexpected performance issues.... Some ORMS can detect and actually solve n+1 query problems. And, as with SQL, you can just specify what you want to eager or lazy load. If you don't like that, you can always use SQL with your ORM. > 3. Troubleshooting is a pain. Especially if you rely on dynamically building queries. No it's not.. Hibernate can check your queries for syntactical problems, which helps testing. The query-builder is just that... a query builder. If you really need to optimize certain things and need some vendor-specific SQL comments to give query hints, you can fall back to using SQL, and STILL use all the benefits of the ORM. > 4. Doesn't treat data as data. First of all data coming from SQL queries is stale the moment it arrives in your objects.... The whole point is that it maps your relational model or objects. But if you don't like that, you can still use the framework to retrieve dataframes / rows. It's not foolish to think about an object model. > 5. No/limited control over writes/updates.... Again, you can use the ORM to update, and either skip or use model validations. You can run update queries, and if you really want, you can just use SQL. Your whole post scream someone who's comfortable with SQL (good thing, I am too, most developers are not), but who has played with some ORM for like 2 hours, and got frustrated with the functionality and didn't take the time to actually read up on the docs. The other type of person with this stance is a front-end developer on some huge site, which needs to squeeze all the performance out of the CPU, where the requests are mostly read-only, and don't really do anything else.. For example showing some posts on your Facebook homepage. The *only* downside of an ORM in that case is some cpu and allocation overhead of mapping your data to objects. In that case, use rust instead of php ;)

by beders 3y ago

jbverschoor 3y ago

5x simply not true

DandyDev 3y ago
That is a cheap comment. Could you elaborate why you disagree with the comment you respond to?
- isbvhodnvemrwvn 3y ago
  Not the original responder - hibernate has had projections to solve #1 for ages, the rest are on point IMO.
- jbverschoor 3y ago
  > 1. inability to represent arbitrary query results.... You can either use any SQL or HQL with hibernate. > 2. lazy loading of attributes - certainly configurable, but if you rely on SELECT statements being generated while you are navigating a 'persistent' object, you will run into unexpected performance issues.... Some ORMS can detect and actually solve n+1 query problems. And, as with SQL, you can just specify what you want to eager or lazy load. If you don't like that, you can always use SQL with your ORM. > 3. Troubleshooting is a pain. Especially if you rely on dynamically building queries. No it's not.. Hibernate can check your queries for syntactical problems, which helps testing. The query-builder is just that... a query builder. If you really need to optimize certain things and need some vendor-specific SQL comments to give query hints, you can fall back to using SQL, and STILL use all the benefits of the ORM. > 4. Doesn't treat data as data. First of all data coming from SQL queries is stale the moment it arrives in your objects.... The whole point is that it maps your relational model or objects. But if you don't like that, you can still use the framework to retrieve dataframes / rows. It's not foolish to think about an object model. > 5. No/limited control over writes/updates.... Again, you can use the ORM to update, and either skip or use model validations. You can run update queries, and if you really want, you can just use SQL. Your whole post scream someone who's comfortable with SQL (good thing, I am too, most developers are not), but who has played with some ORM for like 2 hours, and got frustrated with the functionality and didn't take the time to actually read up on the docs. The other type of person with this stance is a front-end developer on some huge site, which needs to squeeze all the performance out of the CPU, where the requests are mostly read-only, and don't really do anything else.. For example showing some posts on your Facebook homepage. The *only* downside of an ORM in that case is some cpu and allocation overhead of mapping your data to objects. In that case, use rust instead of php ;)