4 ms·

As a rule of thumb, I avoid using the word "proof" in this way. Proof is great as a mathematical noun, a publishing noun, or a baking verb. What you're asking f

As a rule of thumb, I avoid using the word "proof" in this way. Proof is great as a mathematical noun, a publishing noun, or a baking verb. What you're asking for, based on your use of "any proof" is better encapsulated in the word "evidence". Evidence accumulates. Often encapsulated in units called "exhibits". Given some test, if greater than 50% of the evidence leans one way, then you have a preponderance of the evidence. If 75% leans that way, the evidence is "clear and convincing". If 99% leans one way, the evidence is "beyond a reasonable doubt". In this case, we'd start with the test. From Wikipedia, "An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive." Then we look at the top answer on Stack Overflow (2) === Exhibit A === But ORM can be a pain: You have to learn it, and ORM libraries are not lightweight tools; You have to set it up. Same problem. Performance is OK for usual queries, but a SQL master will always do better with his own SQL for big projects. It abstracts the DB. While it's OK if you know what's happening behind the scene, it's a trap for new programmers that can write very greedy statements, like a heavy hit in a for loop. === Exhibit B === Do not try to write your own ORM, unless you are trying to learn something. This is a gigantic piece of work, and the old ones took a lot of time and work before they became reliable. So, I have presented some initial evidence that tends to support the idea that an ORM is an anti-pattern. If you disagree, you are welcome to cite additional evidence to the contrary. But keep in mind the test elements.

hardware2win 3y ago
ORM allows you to get away from writing stringly typed SQL and use correct types instead - reduces amount of boring mistakes ORM allows you to focus more on modeling domain model instead of db model ORM speeds up writing boring queries like insert or update ORM can detect changes and update stuff accordingly ORM prevents people from SQL Injections ORM can manage migrations and db schema versioning ORM allows you to change DBs to some extent easier ORM still allows you to write raw query when you need it Try C#s EF Core with LINQ.
revskill 3y ago
I don't consider "learn something" is anti-pattern. It depends on quality of the library itself to know if it's worth learning. Setting something up is similar. It depends on complexity of toolings. Performance is also dependant on the quality of the generated native query. It abstracts the DB, which i consider a good thing in long term, and of course, some ORM gives you enough escape hatches in a good way. Overall, i love working with a "good" ORM rather than working directly with SQL (for example). But the real world libraries is not good enough for the ORM ecosystem to have good faith on DX side.

hardware2win 3y ago

ORM allows you to get away from writing stringly typed SQL and use correct types instead - reduces amount of boring mistakes ORM allows you to focus more on modeling domain model instead of db model ORM speeds up writing boring queries like insert or update ORM can detect changes and update stuff accordingly ORM prevents people from SQL Injections ORM can manage migrations and db schema versioning ORM allows you to change DBs to some extent easier ORM still allows you to write raw query when you need it Try C#s EF Core with LINQ.

revskill 3y ago

I don't consider "learn something" is anti-pattern. It depends on quality of the library itself to know if it's worth learning. Setting something up is similar. It depends on complexity of toolings. Performance is also dependant on the quality of the generated native query. It abstracts the DB, which i consider a good thing in long term, and of course, some ORM gives you enough escape hatches in a good way. Overall, i love working with a "good" ORM rather than working directly with SQL (for example). But the real world libraries is not good enough for the ORM ecosystem to have good faith on DX side.