3 ms·
You're dismissing ORMs because of one (well-understood and easy to mitigate) downside without considering the upsides. ORM do make development much easier and
by Nextgrid 4y ago
You're dismissing ORMs because of one (well-understood and easy to mitigate) downside without considering the upsides.
ORM do make development much easier and are fine in the majority of cases to begin with. For the edge-cases, some can be addressed by giving the ORM extra hints about your intentions (such as for the N+1 queries problem) and those that can't can be rewritten as raw SQL.
Why dismiss them entirely in favour of Raw SQL if you can get the best of both worlds by picking the appropriate tool for the job?
- Arch-TK 4y agoIf you simply don't attempt to shoehorn your data into a graph structure then you don't need an ORM in the first place. ORMs only make development easier insofar as you insist on turning your relational data into graphs. In all instances I've found that raw SQL or a good query builder (not an ORM, e.g. SQLAlchemy core) and an approach to handling the data as it is (relational) and not as you might want to pretend it to be (graph) is sufficient to ensure the resulting software is easier to develop and maintain. In situations where I have needed graph data I have found graph databases to work well there too.
- dakiol 4y agoHow is the example given in the post an "edge" case? All except the simplest domain models include these kind of relationships (and more complex ones). The Post->Comment->Vote pattern is practically everywhere as soon as you are modeling real-world scenarios.
- isbvhodnvemrwvn 4y agoSolving those issues takes you SIGNIFICANTLY less time than mapping SQL results in any moderately complex relation graph.