21–30 of 136 posts
My hate for ORMs grew proportionally with my usage of NoSQL. It's such a pleasant experience when your domain model fits the data model. Graphs are a good example, but Redis is a better one. When your intention fits a Redis data structure, it's just programming bliss - a few lines of explicit and simple code.
The only way I can use a relational database now is with Sequel.
Because people are scared of things they don't understand? Or because they had one bad experience, years ago, with some home-grown crappy ORM, and now they assume all ORMs are bad? The reasons are legion... The second of those is what I saw at my last job. The tech-lead / architect guy was vehemently anti-ORM... because a previous group (at the same company) had rolled their own ORM in Jython and embedded it into the…
> There is a lot of truth to these charges, but such charges miss a vital piece of context. The object/relational mapping problem is hard. I suspect that context is precisely what underlies the common critiques of ORMs. Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. In my admittedly anecdotal experience, I have…
Bingo. In other words, non-relational queries work well and relational queries don't. When I'm joining multiple tables and looking for specific rows/objects that match multiple restrictions, ORM turns into a migrane of epic proportions. SQL was specifically designed to solve that exact problem. Abstracting away from SQL will simply increase the pain factor.
For the same reason PHP gets so much hate - both are tools with valid uses, but because they make hard things easier for people, that means that people who have no idea what they're doing can do very bad things. Hating on a tool is ridiculous.
ORM is bad because the impedance mismatch between an object and a relational model is very difficult to get right.
Frequently, for example, one iterates over collections of objects in the OO paradigm. A naively written ORM, or one without sufficient introspection into the loop intent, can translate that into N select statements, each incurring a network round trip.
The end result is that OO programmers have to understand not only their object code, but also the relational model, and finally too the ORM's peculiarities and suboptimalities. So in attempting to solve one problem, most of the time you end up with three.
That said, there is a sweet spot in ORMs for simple code (e.g. most web apps, where ActiveRecord and Sequel and the like are fine). But there's no sweet spot for PHP code. Every line written is technical debt.
Earlier quoted context omitted.
Because it has near-zero barrier to entry. That doesn't speak highly of PHP as a language, just on how its deployment strategy is designed.
I don't think Facebook or Yahoo chose PHP because it was easy to write.
> There is a lot of truth to these charges, but such charges miss a vital piece of context. The object/relational mapping problem is hard. I suspect that context is precisely what underlies the common critiques of ORMs. Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. In my admittedly anecdotal experience, I have…
Any good ORM will let you write your query directly, and still save your the work of mapping the resultset to a collection of objects.
Surprised by the pro-ORM comments so far. My hate for ORMs grew proportionally with my usage of NoSQL. It's such a pleasant experience when your domain model fits the data model. Graphs are a good example, but Redis is a better one. When your intention fits a Redis data structure, it's just programming bliss - a few lines of explicit and simple code. The only way I can use a relational database now is with Sequel.
I personally haven't heard/seen anyone griping about ORMs for a couple of years now. I thought the debate was over. Much like you rarely see anyone talk about stored procedures these days.
Please do come and have a talk with my (pointy-haired style) boss :) . I take it you think stored procedures are generally good (at least that's what I think). But some people still believe that they'll migrate database architecture or some such. Also, some ORM's aren't fit for the task and give a bad name (Microsoft's Entity Framework v1 was especially horrible) I'm definitely out of touch and I spend way too much t…
On a more individual level I'm also now finding myself even shying away from complicated SQL queries. I'm finding these days they're unnecessary 90% of the time. Often it's actually faster and more maintainable to pull out a larger amount of data and then do the more specific calculations in code. Even with good indexes, etc.