5 ms·

It never made sense to me how popular ORMs were. The very first time I used one, I understood straight away that it was a bad idea and I never changed my mind a

It never made sense to me how popular ORMs were. The very first time I used one, I understood straight away that it was a bad idea and I never changed my mind about it (though I tried). Why is it that open source software which adds unnecessary complexity and slows down development tends to become popular but open source software which takes away complexity and speeds up development tends to not get any attention. It's like there is some kind of conspiracy.

justaaron 8y ago
webpack and the entire "modern" js frontend... all because of an inability to manage versioning change across the standard browser js api... great for a giant megacorp looking to waste money on busywork and divide the workload across more employees (front-end devops?!?) less useful when you already have to compile a backend, don't really have a problem with ES5, and understand that you are basically only tasked with making your dom updates dependent upon data model changes, YMMV
- gear54rus 8y ago
  so because you don't see the obvious problem with being stuck on a single version of anything forever, webpack, representing progress in this case, is bad? nice try what does versioning has to do with bubbling, wtf?
  - coldtea 8y ago
    >so because you don't see the obvious problem with being stuck on a single version of anything forever, webpack, representing progress in this case, is bad? In fact, the parent does see (and called) that "obvious problem with being stuck on a single version of anything forever". That's why he doesn't cheer for the band-aid solution that's webpack and doesn't thing it "represents progress".
scarface74 8y ago
I feel the same way about most ORMs - except for LINQ. C# treats queries as first class citizens. There is something very powerful about being able to have a method in your repo... public List<Customer> Find(Expression<Func<Customer,T>> expression) {...} and then your client can use any random expression... Find(c => c.age > 18 && c.age < 65 && c.gender == “M”) and have that expression translated to either SQL, MongoQuery, or anything else that has a LINQ provider. If done correctly, not only can you switch between RDMSs, you can switch between an RDMS and a Nosql data store without changing any client code. When you are writing your unit tests, you can use in memory Lists to mock your data store and still test all of your queries without using a database. Of course you also get type safety, autocomplete, and in the case of NoSql data stores, you enforce a schema over a schemaless data store and get to work with strongly typed objects. I’ve never seen any purpose of an ORM outside of LINQ. They just add another level of complexity and still don’t integrate with the host language naturally.
CuriouslyC 8y ago
ORMs are really useful when you want to pull your data in a deeply nested format that a junior developer can work with easily. Manually nesting table rows is tedious, and stitching together data on the fly requires you to understand the complete data model, which might be outside the purview of some developers. I should be clear though, from an architecture standpoint I think it's much better to go straight to SQL, and keep the data unnested. Like anything in life, it's a trade-off. It requires more up-front data model knowledge and more up-front work, but it's much easier to debug, more flexible, and performs better.
- flavious 8y ago
  When I was a junior, I could write my queries in SQL in 30 minutes for the report which was asked from me, but I needed two more days to figure out how to do it with the ORM. For juniors, it's best to have a less abstractions.
akudha 8y ago
I feel the same. In addition to the ORMs, yet another super irritating thing is writing HTML in server side languages like Ruby, PHP etc in the frameworks. It is perfectly possible to just write plain HTML in views and partials and still keep the code clean. Instead, I've to learn yet another un-natural way to write HTML.

justaaron 8y ago

webpack and the entire "modern" js frontend... all because of an inability to manage versioning change across the standard browser js api... great for a giant megacorp looking to waste money on busywork and divide the workload across more employees (front-end devops?!?) less useful when you already have to compile a backend, don't really have a problem with ES5, and understand that you are basically only tasked with making your dom updates dependent upon data model changes, YMMV

gear54rus 8y ago
so because you don't see the obvious problem with being stuck on a single version of anything forever, webpack, representing progress in this case, is bad? nice try what does versioning has to do with bubbling, wtf?
- coldtea 8y ago
  >so because you don't see the obvious problem with being stuck on a single version of anything forever, webpack, representing progress in this case, is bad? In fact, the parent does see (and called) that "obvious problem with being stuck on a single version of anything forever". That's why he doesn't cheer for the band-aid solution that's webpack and doesn't thing it "represents progress".

scarface74 8y ago

I feel the same way about most ORMs - except for LINQ. C# treats queries as first class citizens. There is something very powerful about being able to have a method in your repo... public List<Customer> Find(Expression<Func<Customer,T>> expression) {...} and then your client can use any random expression... Find(c => c.age > 18 && c.age < 65 && c.gender == “M”) and have that expression translated to either SQL, MongoQuery, or anything else that has a LINQ provider. If done correctly, not only can you switch between RDMSs, you can switch between an RDMS and a Nosql data store without changing any client code. When you are writing your unit tests, you can use in memory Lists to mock your data store and still test all of your queries without using a database. Of course you also get type safety, autocomplete, and in the case of NoSql data stores, you enforce a schema over a schemaless data store and get to work with strongly typed objects. I’ve never seen any purpose of an ORM outside of LINQ. They just add another level of complexity and still don’t integrate with the host language naturally.

CuriouslyC 8y ago

ORMs are really useful when you want to pull your data in a deeply nested format that a junior developer can work with easily. Manually nesting table rows is tedious, and stitching together data on the fly requires you to understand the complete data model, which might be outside the purview of some developers. I should be clear though, from an architecture standpoint I think it's much better to go straight to SQL, and keep the data unnested. Like anything in life, it's a trade-off. It requires more up-front data model knowledge and more up-front work, but it's much easier to debug, more flexible, and performs better.

flavious 8y ago
When I was a junior, I could write my queries in SQL in 30 minutes for the report which was asked from me, but I needed two more days to figure out how to do it with the ORM. For juniors, it's best to have a less abstractions.

akudha 8y ago

I feel the same. In addition to the ORMs, yet another super irritating thing is writing HTML in server side languages like Ruby, PHP etc in the frameworks. It is perfectly possible to just write plain HTML in views and partials and still keep the code clean. Instead, I've to learn yet another un-natural way to write HTML.