Why I Hate ORMs (a solicited rant)
A necessary disclaimer...
Everything in the following post that appears to be an opinion most likely is and should be taken as such. My personal view on a topic does not (necessarily) invalidate any other opposing view. Readers should ascribe whatever value they so choose to the information that follows and either adopt it or reject it at their own discretion.
In the comment thread to a post I did on custom validation in Model Glue, I shared the fact that ORMs aren't my friends. In so doing, it prompted another commenter to ask me to share more details about my decision to be anti-ORM, as they too are weighing out the pros and cons of incorporating it:
" Doug,
Can you elaborate on why you've abandoned ORM? I browsed thru your blog but didn't see any references to this decision. I'm wrestling with its costs vs benefits as well and would be interested in hearing from someone further down that path.
Thanks,
Dave "
What follows are those details.
Why I am Anti-ORM
The Beginning
Just over a year ago, my team and I embarked on a journey to learn the ways of the object oriented programmer. We evaluated some of the popular Coldfusion MVC frameworks and decided to go with Model Glue. At the time, the trend was also to utilize other frameworks alongside Model Glue, so we too jumped on the bandwagon, reasoning that if we were going to adopt the tried and true standards of the OO world, we were going to embrace it completely. So, we architected our first MVC application, opting to utilize MG as our MVC framework, Coldspring as our IOC framework, and [brand X] as our ORM. For those of you who may not know what each of these frameworks are for, ModelGlue is the framework that separates, organizes, and "glues" together your views, your CFCs, and the controller CFCs that act as liaison between the other two. Coldspring is the IOC (Inversion of Control) framework whose job it is to manage the relationships between your CFCs. For instance, you might have a User.cfc that needs to perform a function located within another CFC such as Security.cfc. Using Coldspring, you can define that relationship ahead of time and, rather than hard coding the instantiation of your Security.cfc within your User.cfc, Coldspring will do that for you automatically whenever your app asks for the User.cfc. Ah, and now for [brand X]. {brand X] is an ORM framework whose job it is (and here's where my opinion and personal understanding heavily apply) to add a layer between your app and your database. The reason for this, you might ask? The reasons that my team and I saw for doing so were:
1) To allow us to easily change backend database platforms later down the road, should the need occur (not likely, right?)
2) To allow us to take advantage of some of the nifty "helper" features, such as auto-validation and scaffolding (automatically building Create, Update, View, and Delete forms for a given table)
3) To allow us to pre-define relationships between data so that we could "drill down" into child data by calling auto-generated methods, without having to query for it
4) Because using [brand X] was what every CFer "in the know" was doing, so it must be the right thing to do!
Sound like decent reasons, right?
I'll summarize, from my experience, the reasons that ORMs gave me to despise them. I'll try my best not to rant (actually I already did a lot of that in this other post).
The Reasons
The first reason my ORM gave me to hate it was that it forced me to have to synchronize case between field names and elements within different XML files. Coldfusion has LONG been a case-insensitive language for the most part, but suddenly now, as I am embarking on a journey through the foreignness of ORMs, I have to ALSO be mindful that everytime I type in a field name, I had just BETTER make sure I type it exactly the same way every time! Of course, I learned about this the hard way, through many hours of troubleshooting, following nearly useless error messages, and piecing together scraps and tidbits from here and there on the net building myself a "Franken-Solution".
Second reason: the Coldfusion ORM frameworks are a work in progress, and thus subject to undiscovered anomolies coded into their core. While my team and I were burning the midnight oil trying to learn and use our ORM, it kept changing on us. We'd update and replace core files only to find that some behaviors had suddenly changed. The one thing that DIDN'T change were the nearly useless error messages, though...that kept it "interesting" for us.
Hey, this ever happen to you? You're building an application and suddenly realize you need another field in a certain table, so you...go ahead and add it? Sheesh, it happens ten times a day sometimes! A very common occurrence, a very expected occurrence, right? Which leads me to the third reason my ORM gave me to hate it: our ORM didn't take kindly to change. It took us FAR too long to try and figure out how to cause it to see and propagate database changes throughout the app without spilling its groceries into a useless error message. The final solution, that took us weeks of evolving to: nuke it. Just delete the whole cotton-picking cache of files that our ORM had automagically generated for us and FORCE it to recreate them all. This approach defies common sense, and thus it was the end of our evolution and not the beginning. Why's an ORM gotta defy common sense?
The fourth reason: gluttony. As mentioned in the list of reasons why we chose to use an ORM, we wanted to leverage the beauty of pre-defining data relationships and be able to drill down into child data with ease. In theory, this is a beautiful thing. In practice, it's a disgusting hag. The bloated, inefficient objects within objects within objects that get created in this process can cause an app to literally CRAWL. What would take less than a second to perform the traditional way can take many hundreds of times that amount of time when using these auto-generated object nests. When you do take the time to define all of these relationships as they truly are (and good luck getting that right the first five tries), the resulting objects are ginormous and slow as molasses on a cold January morning. Painfully slow. Not acceptable, ORM. Not acceptable.
And ah, the grandest reason of them all that I pretty much despise ORMs: losing my beloved sql. Now, I wouldn't have a problem with losing sql as long as my ORM provides me with a suitable substitute. But it does not. The task of translating a simple sql statement into "ORM-speak" is far, far from simple, my friend. I and others I know have quite literally spent an entire DAY trying to figure out how to write the code, leveraging our ORM, to execute a simple join. Don't get me wrong, it IS do-able. But from the perspective of someone who knows how to query a database, doing the same thing using only ORM objects is convoluted, WAY over-complicated, gluttonous from an efficiency point of view, time consuming, and in the end....what the heck good is it anyway? What did I just do to help myself by spending an entire DAY figuring out how to define object relationships in a way that my ORM likes, defining events that have every parameter present and properly cased, making sure that the database changes I make along the way are actually recognized by my ORM and my application has been properly reinitialized, and then synchronizing the whole thing and crossing my fingers that it'll actually work and not throw me back some useless error? Writing and executing what was and is simple SQL is ridiculously convoluted by an ORM, eats up a huge amount of precious development hours in figuring out how to do it, and gives me only negative return on that investment by creating code that increases my bottom line in IO and makes it so that only another person who has drunk the ORM kool-aid can possibly ever understand. Oh yeah, and when you DO finally figure out how to write a simple join, you then realize that there are actually probably four or five different ways you could have done it using the ORM objects; which one is most efficient? who the heck knows, and you'll only know if you invest the hours to write it with each approach and time it yourself. And even your ORM's BEST and most efficient approach will STILL NOT beat the time you would get by executing straight SQL...there's no way.
Conclusion
What this and any decision comes down to is really just a list of reasons TO do something versus reasons NOT to do it. In this case, based on what I consider to be thorough personal experience combined with that of my peers, adopting an ORM has an extremely sparse list of "Pros" which in no way even come CLOSE to outweighing the list of Cons that come with it.
I realize I didn't do very well at filtering out my ranting. I also realize that, if you happen to be a person who has already gone to ORM prison and now you're used to the lifestyle of having it dwell within your apps, you're going to have a totally different take on it. But I'd be willing to bet money that even you die-hard ORMians felt the same way I do at one point in your J-Curve, only instead of ceasing to knock your head against the wall, you banged a little longer and finally broke through it. Now it's second nature to you to know where NOT to step in order to avoid the landmines, so you can play soccer freely in the minefield having only lost a few virtual limbs in the process. HOWEVER, if you are the person who has yet to step into that tempting and beckoning ORM minefield, if you're still on this side of the kool-aid, you should know that forcing yourself to use and learn an ORM is a bit like forcing yourself to learn to smoke. Yeah, given enough choking, hacking, and puffing, you CAN eventually learn to love the feeling of hot, acrid, killer gases in your lungs; but is the miniscule physical pleasure and social "coolness" worth the initial pain, suffering, and certain long term problems that go with it? I say no way, and after having hacked and puffed on my chosen ORM for a solid six months, I say no way to that as well.
I am of course committing a social faux pas by pre-judging all ORMs based on my experience with one, much the same way as it is commonly said that you can't judge all women by the way one woman treated you. But you know what? Even the slickest ORM is STILL only going to provide me with 2 or 3 pros, tops, and will STILL of necessity be adding overhead to my application's efficiency and learning curve to my timeline. From that perspective then, yes, I AM pre judging and have every intention of remaining "ORM Celibate" from here on out. I've worked on several applications since the one I mentioned earlier, all completely without an ORM involved, and have been utterly delighted with their performance. Good riddance, ORMs, I'm not missing you at all and will probably never recommend you.
Doug out.
Everything in the following post that appears to be an opinion most likely is and should be taken as such. My personal view on a topic does not (necessarily) invalidate any other opposing view. Readers should ascribe whatever value they so choose to the information that follows and either adopt it or reject it at their own discretion.
In the comment thread to a post I did on custom validation in Model Glue, I shared the fact that ORMs aren't my friends. In so doing, it prompted another commenter to ask me to share more details about my decision to be anti-ORM, as they too are weighing out the pros and cons of incorporating it:
" Doug,
Can you elaborate on why you've abandoned ORM? I browsed thru your blog but didn't see any references to this decision. I'm wrestling with its costs vs benefits as well and would be interested in hearing from someone further down that path.
Thanks,
Dave "
What follows are those details.
Why I am Anti-ORM
The Beginning
Just over a year ago, my team and I embarked on a journey to learn the ways of the object oriented programmer. We evaluated some of the popular Coldfusion MVC frameworks and decided to go with Model Glue. At the time, the trend was also to utilize other frameworks alongside Model Glue, so we too jumped on the bandwagon, reasoning that if we were going to adopt the tried and true standards of the OO world, we were going to embrace it completely. So, we architected our first MVC application, opting to utilize MG as our MVC framework, Coldspring as our IOC framework, and [brand X] as our ORM. For those of you who may not know what each of these frameworks are for, ModelGlue is the framework that separates, organizes, and "glues" together your views, your CFCs, and the controller CFCs that act as liaison between the other two. Coldspring is the IOC (Inversion of Control) framework whose job it is to manage the relationships between your CFCs. For instance, you might have a User.cfc that needs to perform a function located within another CFC such as Security.cfc. Using Coldspring, you can define that relationship ahead of time and, rather than hard coding the instantiation of your Security.cfc within your User.cfc, Coldspring will do that for you automatically whenever your app asks for the User.cfc. Ah, and now for [brand X]. {brand X] is an ORM framework whose job it is (and here's where my opinion and personal understanding heavily apply) to add a layer between your app and your database. The reason for this, you might ask? The reasons that my team and I saw for doing so were:
1) To allow us to easily change backend database platforms later down the road, should the need occur (not likely, right?)
2) To allow us to take advantage of some of the nifty "helper" features, such as auto-validation and scaffolding (automatically building Create, Update, View, and Delete forms for a given table)
3) To allow us to pre-define relationships between data so that we could "drill down" into child data by calling auto-generated methods, without having to query for it
4) Because using [brand X] was what every CFer "in the know" was doing, so it must be the right thing to do!
Sound like decent reasons, right?
I'll summarize, from my experience, the reasons that ORMs gave me to despise them. I'll try my best not to rant (actually I already did a lot of that in this other post).
The Reasons
The first reason my ORM gave me to hate it was that it forced me to have to synchronize case between field names and elements within different XML files. Coldfusion has LONG been a case-insensitive language for the most part, but suddenly now, as I am embarking on a journey through the foreignness of ORMs, I have to ALSO be mindful that everytime I type in a field name, I had just BETTER make sure I type it exactly the same way every time! Of course, I learned about this the hard way, through many hours of troubleshooting, following nearly useless error messages, and piecing together scraps and tidbits from here and there on the net building myself a "Franken-Solution".
Second reason: the Coldfusion ORM frameworks are a work in progress, and thus subject to undiscovered anomolies coded into their core. While my team and I were burning the midnight oil trying to learn and use our ORM, it kept changing on us. We'd update and replace core files only to find that some behaviors had suddenly changed. The one thing that DIDN'T change were the nearly useless error messages, though...that kept it "interesting" for us.
Hey, this ever happen to you? You're building an application and suddenly realize you need another field in a certain table, so you...go ahead and add it? Sheesh, it happens ten times a day sometimes! A very common occurrence, a very expected occurrence, right? Which leads me to the third reason my ORM gave me to hate it: our ORM didn't take kindly to change. It took us FAR too long to try and figure out how to cause it to see and propagate database changes throughout the app without spilling its groceries into a useless error message. The final solution, that took us weeks of evolving to: nuke it. Just delete the whole cotton-picking cache of files that our ORM had automagically generated for us and FORCE it to recreate them all. This approach defies common sense, and thus it was the end of our evolution and not the beginning. Why's an ORM gotta defy common sense?
The fourth reason: gluttony. As mentioned in the list of reasons why we chose to use an ORM, we wanted to leverage the beauty of pre-defining data relationships and be able to drill down into child data with ease. In theory, this is a beautiful thing. In practice, it's a disgusting hag. The bloated, inefficient objects within objects within objects that get created in this process can cause an app to literally CRAWL. What would take less than a second to perform the traditional way can take many hundreds of times that amount of time when using these auto-generated object nests. When you do take the time to define all of these relationships as they truly are (and good luck getting that right the first five tries), the resulting objects are ginormous and slow as molasses on a cold January morning. Painfully slow. Not acceptable, ORM. Not acceptable.
And ah, the grandest reason of them all that I pretty much despise ORMs: losing my beloved sql. Now, I wouldn't have a problem with losing sql as long as my ORM provides me with a suitable substitute. But it does not. The task of translating a simple sql statement into "ORM-speak" is far, far from simple, my friend. I and others I know have quite literally spent an entire DAY trying to figure out how to write the code, leveraging our ORM, to execute a simple join. Don't get me wrong, it IS do-able. But from the perspective of someone who knows how to query a database, doing the same thing using only ORM objects is convoluted, WAY over-complicated, gluttonous from an efficiency point of view, time consuming, and in the end....what the heck good is it anyway? What did I just do to help myself by spending an entire DAY figuring out how to define object relationships in a way that my ORM likes, defining events that have every parameter present and properly cased, making sure that the database changes I make along the way are actually recognized by my ORM and my application has been properly reinitialized, and then synchronizing the whole thing and crossing my fingers that it'll actually work and not throw me back some useless error? Writing and executing what was and is simple SQL is ridiculously convoluted by an ORM, eats up a huge amount of precious development hours in figuring out how to do it, and gives me only negative return on that investment by creating code that increases my bottom line in IO and makes it so that only another person who has drunk the ORM kool-aid can possibly ever understand. Oh yeah, and when you DO finally figure out how to write a simple join, you then realize that there are actually probably four or five different ways you could have done it using the ORM objects; which one is most efficient? who the heck knows, and you'll only know if you invest the hours to write it with each approach and time it yourself. And even your ORM's BEST and most efficient approach will STILL NOT beat the time you would get by executing straight SQL...there's no way.
Conclusion
What this and any decision comes down to is really just a list of reasons TO do something versus reasons NOT to do it. In this case, based on what I consider to be thorough personal experience combined with that of my peers, adopting an ORM has an extremely sparse list of "Pros" which in no way even come CLOSE to outweighing the list of Cons that come with it.
I realize I didn't do very well at filtering out my ranting. I also realize that, if you happen to be a person who has already gone to ORM prison and now you're used to the lifestyle of having it dwell within your apps, you're going to have a totally different take on it. But I'd be willing to bet money that even you die-hard ORMians felt the same way I do at one point in your J-Curve, only instead of ceasing to knock your head against the wall, you banged a little longer and finally broke through it. Now it's second nature to you to know where NOT to step in order to avoid the landmines, so you can play soccer freely in the minefield having only lost a few virtual limbs in the process. HOWEVER, if you are the person who has yet to step into that tempting and beckoning ORM minefield, if you're still on this side of the kool-aid, you should know that forcing yourself to use and learn an ORM is a bit like forcing yourself to learn to smoke. Yeah, given enough choking, hacking, and puffing, you CAN eventually learn to love the feeling of hot, acrid, killer gases in your lungs; but is the miniscule physical pleasure and social "coolness" worth the initial pain, suffering, and certain long term problems that go with it? I say no way, and after having hacked and puffed on my chosen ORM for a solid six months, I say no way to that as well.
I am of course committing a social faux pas by pre-judging all ORMs based on my experience with one, much the same way as it is commonly said that you can't judge all women by the way one woman treated you. But you know what? Even the slickest ORM is STILL only going to provide me with 2 or 3 pros, tops, and will STILL of necessity be adding overhead to my application's efficiency and learning curve to my timeline. From that perspective then, yes, I AM pre judging and have every intention of remaining "ORM Celibate" from here on out. I've worked on several applications since the one I mentioned earlier, all completely without an ORM involved, and have been utterly delighted with their performance. Good riddance, ORMs, I'm not missing you at all and will probably never recommend you.
Doug out.
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Re: Why I Hate ORMs (a solicited rant)
Interesting insight. I haven't dipped into the ORM KookAid (yet). It will be interesting to see if this stirs up any interesting comments.
Posted by Jim Priest on May 1, 2008 at 12:36 PM
Re: Why I Hate ORMs (a solicited rant)
I know what you mean. Went to a dentist once. He was lousy. Vowed never to have my teeth looked at again. Saw something in the paper about how a doctor mis-diagnosed and killed someone, so I've decided never to go to hospital. Tried outsourcing a project to a programmer on rent a coder for $4/hr and they sucked, so it's clear programmers are a waste of space. I also heard cars crash sometimes, so I walk everywhere - just to be safe.
Posted by Peter Bell on May 1, 2008 at 3:53 PM
Re: Why I Hate ORMs (a solicited rant)
doug,
you hit the nail on the head. of all the readily available orms for cf out there, none of them live up to expectations. their either too slow (transfer) or so complicated to use (reactor) that they aren't worth using and just slow you down.
when you think about it, it's pathetic that a language as mature as cf doesn't have this "plugin". look at how many other languages are new the web arena (ruby and python off the top of my head) that have more mature orms and frameworks.
it always seems like cf is playing catchup with everything that is out there.
you hit the nail on the head. of all the readily available orms for cf out there, none of them live up to expectations. their either too slow (transfer) or so complicated to use (reactor) that they aren't worth using and just slow you down.
when you think about it, it's pathetic that a language as mature as cf doesn't have this "plugin". look at how many other languages are new the web arena (ruby and python off the top of my head) that have more mature orms and frameworks.
it always seems like cf is playing catchup with everything that is out there.
Posted by tony petruzzi on May 1, 2008 at 3:58 PM
Re: Why I Hate ORMs (a solicited rant)
Doug,
I heartily agree with you, regarding what's available in the CF space. Clunky, slow, and not very fun to use. Move to Hibernate w/ Java, and it's a different story. Still a bunch to learn, but it's not really in your way. Try Grails (which is built atop Hibernate), and the ORM is completely transparent. You just define a property in your object and you're done.
So don't just ORM by what CF has to offer, because the offerings are weak.
I heartily agree with you, regarding what's available in the CF space. Clunky, slow, and not very fun to use. Move to Hibernate w/ Java, and it's a different story. Still a bunch to learn, but it's not really in your way. Try Grails (which is built atop Hibernate), and the ORM is completely transparent. You just define a property in your object and you're done.
So don't just ORM by what CF has to offer, because the offerings are weak.
Posted by Barney Boisvert on May 1, 2008 at 4:42 PM
Re: Why I Hate ORMs (a solicited rant)
Outstanding delivery, Peter! Really. However, I think there's a disconnect between your analogy and my point about ORMs. All of the items you mentioned are needful, and are actually useful for making life easier and more efficient. In the ORM world, there isn't one ORM that is "the exception" and doesn't make life easier...ALL of them are an added layer of complexity that adds overhead and slope to the J Curve without giving much of anything back. A more fitting analogy, I think, would be to compare the invention of the ORM with a man who comes up with a brilliant, multi-step, hydraulic device for rolling his chair across the room. Uh, what for?
Then again, perhaps I'm missing some vital epiphany that one day will come my way and I'll be retracting this entire viewpoint. :)
Then again, perhaps I'm missing some vital epiphany that one day will come my way and I'll be retracting this entire viewpoint. :)
Posted by dougboude on May 1, 2008 at 4:46 PM
Re: Why I Hate ORMs (a solicited rant)
Nice post Doug, I must admit I've wondered at the reason for using an ORM unless you have a specific need and not just using it because that's what all the "cool kids" are doing.
Still, the highlight for me was:
>Yeah, given enough choking, hacking, and puffing, you CAN eventually learn to love the feeling of hot, acrid, killer gases in your lungs;
Damn man, that was too good :)
Still, the highlight for me was:
>Yeah, given enough choking, hacking, and puffing, you CAN eventually learn to love the feeling of hot, acrid, killer gases in your lungs;
Damn man, that was too good :)
Posted by Michael Sharman on May 1, 2008 at 7:41 PM
Re: Why I Hate ORMs (a solicited rant)
I too played with ORM's and in the end i found them too slow and cumbersome as well. Manually redefining DB metadata in XML when it already exists is painful.
Over the years i have found using a code generator 'once' is much easier and static cfc's are a lot more performant.. and SQL ain't so bad anyway!
Over the years i have found using a code generator 'once' is much easier and static cfc's are a lot more performant.. and SQL ain't so bad anyway!
Posted by zac spitzer on May 1, 2008 at 8:52 PM
Re: Why I Hate ORMs (a solicited rant)
I would say keep trying. I'll plug Squidhead (http://squidhead.riaforge.org/) which while not techncally an orm, dynamically generates dao's and gateways for you, using stored procedures. To add functionality you add stored procedures in sql.
In response to you on Peter's remark, they do serve a purpose: to handle the knuckle-headed code that everyone writes, so you can focus on where you actually add value.
In response to you on Peter's remark, they do serve a purpose: to handle the knuckle-headed code that everyone writes, so you can focus on where you actually add value.
Posted by Terrence Ryan on May 2, 2008 at 11:59 AM
Re: Why I Hate ORMs (a solicited rant)
Thanks for your insight into ORMs. Because of all the "buzz" about ORMs increasing developer productivity, I was attempting to start the jump into it. I thought I must be coming up short mentally, because the learning was hard and the productivity was not materializing. You have made me feel better, that manually using SQL and creating the necessary CFCs are not necessarily non-productive.
Posted by Bill Knight on May 2, 2008 at 2:28 PM
Re: Why I Hate ORMs (a solicited rant)
"A more fitting analogy, I think, would be to compare the invention of the ORM with a man who comes up with a brilliant, multi-step, hydraulic device for rolling his chair across the room. Uh, what for?"
That's one of the best analogies I've seen for ORMs EVER! Brilliant! I'd like to see what Doug Hughes would say about that (by the way, you did say that you guys were using Reactor in your post...not sure if you meant to leak that or not).
By the way, your turing test for these comments is painful. I know we all hate spam, but there are better ways to prevent it than this...it took me too long to figure out what letter comes before h in the alphabet. It's your blog, so do whatever you want, but I suggest you take a look at Ben Nadel's blog for some user friendly ways to stop spam comments.
That's one of the best analogies I've seen for ORMs EVER! Brilliant! I'd like to see what Doug Hughes would say about that (by the way, you did say that you guys were using Reactor in your post...not sure if you meant to leak that or not).
By the way, your turing test for these comments is painful. I know we all hate spam, but there are better ways to prevent it than this...it took me too long to figure out what letter comes before h in the alphabet. It's your blog, so do whatever you want, but I suggest you take a look at Ben Nadel's blog for some user friendly ways to stop spam comments.
Posted by Jake Munson on May 2, 2008 at 3:05 PM
Re: Why I Hate ORMs (a solicited rant)
I think Peter got this completely right. Your arguments sound like they are similar to mine with a particular ORM but, unlike you, I chose not to write off the entire group because of a single experience. You generalize and are, in fact, wrong in many cases. For example, I use Transfer and it supports lazy-loading which negates your objects within objects within objects argument. Transfer has an excellent caching layer and has always performed well enough in my (and many other people's) experience. Transfer also allows you to use your own SQL with the exception of the DAO (I believe). But why the hell would you want to write DAO code? What special SQL are you doing there?
Performance in Transfer still not enough? Plug in Hibernate. However, writing off ORMs in general (and advising others on the same due to your own lack of a deep understanding of all the ORM frameworks) is just a bad idea, in my opinion (in fact, by your description, I can guess which ORM you based your entire opinion on). Don't get me wrong Doug, I think you are a smart guy who generally writes very smart stuff, but in this case you are poorly informed.
Performance in Transfer still not enough? Plug in Hibernate. However, writing off ORMs in general (and advising others on the same due to your own lack of a deep understanding of all the ORM frameworks) is just a bad idea, in my opinion (in fact, by your description, I can guess which ORM you based your entire opinion on). Don't get me wrong Doug, I think you are a smart guy who generally writes very smart stuff, but in this case you are poorly informed.
Posted by Brian Rinaldi on May 5, 2008 at 3:14 PM
Re: Why I Hate ORMs (a solicited rant)
Thanks for the input, Brian. I think it's extremely important to get all sides to a topic...helps balance it all out.
Posted by dougboude on May 5, 2008 at 3:42 PM
Re: Why I Hate ORMs (a solicited rant)
I thought I would let this thread settle a little before deciding to reply.
Doug, I think it's a shame that you've decided to throw the baby out with the bathwater, but at the very least, I can respect that you've made a decision based on past experience, however I would recommend that you not close the door all together. You may want to keep an eye on the ORM space, maybe in 3 months, 6 months, or even a few years, you may find things are at a point at which you may be interested in using them again.
Obviously, I'm a huge fan of ORMs (having written one), and I find my development productivity and system maintainability get incredibly enhanced, especially on large scale applications. I'd be more than happy to have an IM / Skype conversation with you so we can discuss your thoughts, and see where your major pain points are at, and find if there are solutions. I'm always for fixing issues in the ORM space, so feel free to drop me an email, and we can schedule something.
In regards to a couple of the comments made on this post:
@tony petruzzi - I'm sorry to hear you had performance issues with Transfer. I had a look on the mailing list to see if you had voiced any issues you had had, as I was worried that I hadn't responded to any of your questions. I couldn't find anything, but the offer still stands for you to fire off any performance issues you had with Transfer to the mailing list, and I will happy to help you out, and see what can be done.
@Barney Boisvert - I'm sorry to hear that you think the time and effort I have spent on Transfer has resulted in a 'weak' product. Not to mention 'Clunky, slow, and not very fun to use'. That is usually the exact opposite of the reaction I usually get from Transfer. Please feel free to share your thoughts on the mailing list, so we can enhance Transfer into a 'strong' product.
@Bill Knight - You didn't say what ORM platform you are on, but also, the Transfer mailing list is a great resource, and we would be more than happy to help clarify any questions or issues you have with Transfer, to help ease the learning curve.
@zac spitzer - Same as above.
I hope my comments mean that some people won't read this, and simply decide that ORM is a bad way to go. Obviously, there is no silver bullet, and there are some cases in which an ORM isn't the way to go, but I feel it is a strong option in many cases, and as such, should be at the very least be considered.
Doug, I think it's a shame that you've decided to throw the baby out with the bathwater, but at the very least, I can respect that you've made a decision based on past experience, however I would recommend that you not close the door all together. You may want to keep an eye on the ORM space, maybe in 3 months, 6 months, or even a few years, you may find things are at a point at which you may be interested in using them again.
Obviously, I'm a huge fan of ORMs (having written one), and I find my development productivity and system maintainability get incredibly enhanced, especially on large scale applications. I'd be more than happy to have an IM / Skype conversation with you so we can discuss your thoughts, and see where your major pain points are at, and find if there are solutions. I'm always for fixing issues in the ORM space, so feel free to drop me an email, and we can schedule something.
In regards to a couple of the comments made on this post:
@tony petruzzi - I'm sorry to hear you had performance issues with Transfer. I had a look on the mailing list to see if you had voiced any issues you had had, as I was worried that I hadn't responded to any of your questions. I couldn't find anything, but the offer still stands for you to fire off any performance issues you had with Transfer to the mailing list, and I will happy to help you out, and see what can be done.
@Barney Boisvert - I'm sorry to hear that you think the time and effort I have spent on Transfer has resulted in a 'weak' product. Not to mention 'Clunky, slow, and not very fun to use'. That is usually the exact opposite of the reaction I usually get from Transfer. Please feel free to share your thoughts on the mailing list, so we can enhance Transfer into a 'strong' product.
@Bill Knight - You didn't say what ORM platform you are on, but also, the Transfer mailing list is a great resource, and we would be more than happy to help clarify any questions or issues you have with Transfer, to help ease the learning curve.
@zac spitzer - Same as above.
I hope my comments mean that some people won't read this, and simply decide that ORM is a bad way to go. Obviously, there is no silver bullet, and there are some cases in which an ORM isn't the way to go, but I feel it is a strong option in many cases, and as such, should be at the very least be considered.
Posted by Mark Mandel on May 5, 2008 at 3:52 PM
Re: Why I Hate ORMs (a solicited rant)
Mark, thank you very much for taking the time to be so thoughtful (and gentle ;) ) with your comments. Quite some time ago, I "wrote off" flex as well for having given me a similar experience, but I do find myself now coming back around to feeling the urge to give it another go now that it's had time to evolve. The same will undoubtedly hold true for me regarding ORMs, I just can't say how long it'll take for the bad taste to wear off. Your non-reactive approach (no pun intended) have helped curb the bitterness on my palate; There is the distinct possibility that I might just go out and see if I can find the baby. ;)
Posted by dougboude on May 5, 2008 at 4:36 PM
Re: Why I Hate ORMs (a solicited rant)
Since Terrence already plugged Squidhead (about which I have heard many good things), I will go ahead and plug DataMgr (http://datamgr.riaforge.org/). It is a thin data access layer that I feel provides many of the advantages of an ORM without the overhead.
That being said, I agree with Peter and Mark's comments that one bad experience shouldn't be decisive for all ORMs. This is especially true because your problems seemed specific to the implementation details of one ORM rather than problems that you had with the concept of an ORM itself.
That being said, I agree with Peter and Mark's comments that one bad experience shouldn't be decisive for all ORMs. This is especially true because your problems seemed specific to the implementation details of one ORM rather than problems that you had with the concept of an ORM itself.
Posted by Steve Bryant on May 5, 2008 at 5:07 PM
Re: Why I Hate ORMs (a solicited rant)
When I read a rant like yours, my first thought is that you were misusing the framework and got burned. Since you don't state which framework or exactly what you were doing, it's very hard to take your rant seriously.
No packaged solution is going to be a silver bullet but as a few people have wisely noted, you really are throwing the baby out with the bathwater here. I have worked extensively with Reactor and moved over to Transfer for a variety of reasons and have a lot of success with Transfer. You have to know what you're doing in order to avoid pitfalls tho'...
No packaged solution is going to be a silver bullet but as a few people have wisely noted, you really are throwing the baby out with the bathwater here. I have worked extensively with Reactor and moved over to Transfer for a variety of reasons and have a lot of success with Transfer. You have to know what you're doing in order to avoid pitfalls tho'...
Posted by Sean Corfield on May 6, 2008 at 1:40 AM
Re: Why I Hate ORMs (a solicited rant)
A lot of comments supporting negative experiences, so I'll just add one positive response. We are using Transfer with M/G (and Fusebox). It has certainly lived up to it's promise of aiding productivity, and no performance problems. However we don't use it for everything, and where complex SQL is required (reporting for example - yikes you should see some of our queries) we do it outside the ORM framework. Another benefit I have found personally, is that it tends to facilitate an OO approach to development because of the way it decouples the relational restrictions of an RDBMS - but that might just be me. It should be said that although we make full use of compositional possibilities provided by the ORM - we don't go crazy and have huge nested objects
Posted by Richard on May 6, 2008 at 6:50 AM
Re: Why I Hate ORMs (a solicited rant)
@Richard... would you mind elaborating on "decouples the relational restrictions of an RDBMS" ... not just the clinical definition of that, but what it is in the context of your application of it and how it made life easier? For instance, what you would have had to do if you HADN'T decoupled that relationship vs what you were able to do? Perhaps you could do a post on your blog and put the link to it here in these comments? I do believe that there are a lot of people out there who, when they think about ORMs and are weighing out the pros vs cons, may not be fully aware of just what all the pros are. I'm pretty sure I fall into that category as well, so anybody out there who could expound upon the virtues of ORMs in a practical (not theoretical) sense, I think that would be uber useful to "the rest of us".
Posted by dougboude on May 6, 2008 at 10:27 AM
Re: Why I Hate ORMs (a solicited rant)
Doug - well first of all the blogs i have, such as they are, are more concerned with photography, so posting there might confuse everyone, not least me.
I'm not suggesting that an ORM allows you to actually DO anything that you wouldn't achieve by other means - however if you come from an RDBMS background and are making the transition to more OO development and design I think it helps indirectly because you start putting your objects first as opposed to your tables and relationships. As I said in the previous comment I regard this as something that has helped me personally, and may not be universal. I started looking at OO "principles" when I felt that the (normalised) relational models were too rigid to map many real life scenarios. Now some people are probably going to jump on this and say "you should go and learn OO from first principles and really understand it before you try and play with the grown ups" but I have found that using an ORM jump started this process. I mean, it may have left me technically and philosophically crippled as far as understanding OO is concerned, but using the proof of the pudding test, it seems to have helped us.
I'm not suggesting that an ORM allows you to actually DO anything that you wouldn't achieve by other means - however if you come from an RDBMS background and are making the transition to more OO development and design I think it helps indirectly because you start putting your objects first as opposed to your tables and relationships. As I said in the previous comment I regard this as something that has helped me personally, and may not be universal. I started looking at OO "principles" when I felt that the (normalised) relational models were too rigid to map many real life scenarios. Now some people are probably going to jump on this and say "you should go and learn OO from first principles and really understand it before you try and play with the grown ups" but I have found that using an ORM jump started this process. I mean, it may have left me technically and philosophically crippled as far as understanding OO is concerned, but using the proof of the pudding test, it seems to have helped us.
Posted by Richard on May 6, 2008 at 10:56 AM