3 ms·
I understand the author's frustration, but his railing against ORMs is misplaced. First, if you don't want to use an ORM or your application doesn't warrant one
by macspoofing 6y ago
I understand the author's frustration, but his railing against ORMs is misplaced. First, if you don't want to use an ORM or your application doesn't warrant one, then don't use one. Also, all ORMs let you do raw SQL because there will be times where the ORM abstraction will be too cumbersome.
But to be clear, either you use an ORM or you're going to invent a new ORM because your app doesn't talk in SQL, it talks in Objects - so whatever you do, there will be some mapping between the SQL query response, and objects that you will need to create to pass around in your app. If your app is expected to work with different databases, each with their own SQL flavor, you're going to have abstract that as well.
And of course, ORMs tend to have good sets of defaults built in (like proper escapes). So whatever ORM-like framework you build, you'll have to take care to cover that case, otherwise you're back in the bad old world of SQL injection.
- otabdeveloper4 6y ago> your app doesn't talk in SQL, it talks in Objects Speak for yourself. My app talks in dataframes.
- macspoofing 6y agoThen maybe ORM isn't for you?
- otabdeveloper4 6y agoExactly. I'm just complaining about the "everything is a webapp backend written in a scripting language" mentality that pervades everything in IT now.
- TuringTest 6y agoBut aren't dataframes just objects where each attribute returns an array of values instead of a scalar?
- pwinnski 6y agoMy app often talks in Objects, but my scripts talk in SQL.
- qudat 6y ago> Also, all ORMs let you do raw SQL because there will be times where the ORM abstraction will be too cumbersome. "Learn how to master {flavor} ORM and when you've spent hours digging through documentation, stack overflow posts, and src code to find it isn't simple to do in {flavor}, use raw SQL." This argument that "you can always drop into raw SQL" skips the fact that the code will not be merged if it can be done in the ORM because ThisIsTheWay(tm). I find query builders to be a nice blend between raw SQL and the ability to write programmatic queries. The APIs tend to be relatively consistent between libraries since they map directly to SQL statements.
- lelanthran 6y ago> your app doesn't talk in SQL, it talks in Objects Maybe that's the problem? It might just be that OOP is a poor fit for large datasets :-/ Using OOP for results from a RDBMS is banging a square peg into a round hole: with a big enough hammer you'll eventually get it in, but the results are not going to be pretty. If all the data is relational, and you're trying to enforce some sort of hierarchy on it, whether you're using an ORM or not is irrelevant, you've already lost the aesthetics war.