I actually read the horrors of ORM post by Sean before writing this response.
Understood most of it's hints. But surely we must have come a long way since 2006. Else the gods of platform development should have given up on ORM. It is unfair to not let a ORM die hard to present his side of the story. It just might be most convincing to hear about a recent headache on a major project that uses a major ORM tool. We develop in jee + spring and ORM is part of the process. Are you telling me that in couple of years we will see pain larger than the ensuing benefits of automatic schema & data access code management? Will be reading more of the links in there on ORM...but would be useful to get more recent concrete evidence of meaningful pain. Anybody? -Nitish 2011/10/1 Matthew Woodward <[email protected]> > On Sat, Oct 1, 2011 at 1:18 AM, Sean Corfield <[email protected]>wrote: > >> I think this would be a terrible idea. I think Adobe made a big >> mistake adding Hibernate ORM to ColdFusion and I think the Railo team >> have had to waste a lot of cycles on implementing it that could have >> been spent on features that would benefit more users. >> > > Thanks so much for sharing Railo's experiences Sean. As you can imagine > we've debated this but to most of the steering committee the cost/benefit > analysis doesn't come out favorably. > > If nothing else, people should take away from these discussions that ORM is > a tool like any other, and to use it effectively you have to get your hands > dirty despite all the sales pitches to the contrary. It's not a silver > bullet. > > The typical progression I've seen as people start getting into ORM is that > it's great for simple little apps you use to get familiar with the tool. > Then you start doing more complex things and you have to actually learn the > tool, not just blindly throw stuff at it. Then you wonder why it's behaving > the way it is (you can EASILY shoot yourself in the foot doing things that > *seem* perfectly logical in Hibernate), so you dig in more and learn all the > tool's quirks. Then you run into situations where you have to write your own > XML files because the default stuff doesn't work, and wrangle with the > default Hibernate session behavior because it won't work for your situation, > and write HQL because Hibernate won't quite do what you need it to do ... > and then you start thinking maybe writing your own SQL ain't all that bad. > > The other issue is that you're using ORM ostensibly to save development > time, and in exchange your application takes a performance hit at run time. > That's never seemed like a good trade-off to me. > http://www.iheavy.com/2011/08/26/5-things-are-toxic-to-scalability/ > > And be SURE and read the "ORM is the Vietnam of Computer Science" link Sean > provided. Required reading if you're even considering using ORM. > > All this being said, I'm sure there are people using ORM effectively once > they learn all the quirks, or maybe some people tend to write apps for which > ORM is perfectly suited, but if anyone is thinking "oh if I just had ORM I'd > cut my development time in half and never have to think about persistence > again," you're sorely mistaken. > > ORM is a big, hairy, complex problem to solve and even with a best-of-breed > tool such as Hibernate, if you do decide to use it you better buy a couple > of the big-ass books on it (Java Persistence With Hibernate is an excellent > one) and learn the tool inside and out. If you don't you may find yourself > left holding an unpleasant-smelling bag either during development, or worse, > when your application goes into production. > > And this is true for every app ORM or no, but if you DO use ORM *for crying > out loud load test your application*. I've heard way too many horror stories > from people who build an app around ORM with small datasets and it works > great in development, then they go into production and it's slow as hell, > they start getting out of memory errors, they realize that some seemingly > logical ORM operation they're doing pulls back everything in their database > ... > > The best way to not have to write SQL for your applications? Use a NoSQL > database. :-) Totally different topic but I've been using CouchDB a great > deal lately and that actually *removes* the object-relational impedance > mismatch as opposed to giving you a complex tool to deal with it for you. > That to me has felt like a huge weight lifted off my applications, whereas > ORM never felt that way. > > Or if you do your homework and decide you love Hibernate you can write your > model in Java. Ultimately that'd probably give you far fewer headaches. > > -- > Matthew Woodward > [email protected] > http://blog.mattwoodward.com > identi.ca / Twitter: @mpwoodward > > Please do not send me proprietary file formats such as Word, PowerPoint, > etc. as attachments. > http://www.gnu.org/philosophy/no-word-attachments.html > > -- > official tag/function reference: http://openbd.org/manual/ > mailing list - http://groups.google.com/group/openbd?hl=en > -- -Nitish "Faith is a free Option" http://www.forcesofindia.com/profiles/np -- official tag/function reference: http://openbd.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
