In Defense of ORMs
Martin Fowler in a post defending the role of ORMs:
As you might have gathered, I think NoSQL is technology to be taken very seriously. If you have an application problem that maps well to a NoSQL data model - such as aggregates or graphs - then you can avoid the nastiness of mapping completely. Indeed this is often a reason I’ve heard teams go with a NoSQL solution.
Truth is that some NoSQL databases are getting more mapping libraries and frameworks than what I’ve seen done for relational databases before. Even worse, there are attempts to hide all NoSQL databases behind the same libraries, specs, or APIs. I think that the old principle of decoupling the application from the underlying database is way too ingrained in the software community, so much that almost nobody is asking the real questions: will I really need to change the data storage, will it actually work as planned, or what will I lose if I add just another indirection layer?
As Martin Fowler correctly emphasizes in his post, the real benefit of ORMs comes from eliminating the plumbing :
A framework that allows me to avoid 80% of that [boiler-plate code] is worthwhile even if it is only 80%. The problem is in me for pretending it’s 100% when it isn’t.
But that doesn’t mean that everyone should create its own mapping library/framework for each and every project.
Original title and link: In Defense of ORMs (©myNoSQL)
