I think my first post will start with some venting so bear with me.
ORM solutions have really made a huge impact on software development with relational databases. It’s pretty much expected from any modern object oriented language to have a built-in ORM solution and/or multiple 3rd party implementations of one.
You could even write a pretty impressive list of benefits of ORMs like productivity, avoidance of vendor lock-in (except DB specific ORMs), and maintenance. But in spite of all this, I do find that ORMs have a very real and prevalent hidden cost:
ORMs set the bar too low for who gets to write data access code
You might have seen this happen, or you may been that person once, but time and again i’ve seen how the lack of understanding of what’s happening “behind the scenes” cause very painful performance, stability, and design issues: 1-n problems, fetching too much data, ignoring batch updates, etc. to name just a few common ones.
ORMs take the discipline of fine-tuned and precise database interaction and takes a huge warm dump on it.
Now don’t be mistaken, the elite can and will use ORMs in the best possible way and in all the right places, but let’s be honest about the majority. I’ve seen the blank stare with eyes glazed when I asked a developer why they wrote 3 nested loops to find a specific value of the child of the child of a mapped ORM entity instead of just writing a specific query for it. Or why they retrieved and iterated over all 5 million items to set the same value of of the same field instead of writing an update statement.
Somehow people assume that writing specific queries for specific cases when using an ORM is an admission of defeat when they can easily just traverse the object graph and call their setters and getters. It all comes crashing down though when you have enough data.
In the end using ORMs properly requires even more knowledge and ability and it should be entrusted to those people who can get it right.
Those of you have passed this hurdle should congratulate yourselves. There aren’t many of you.
n0tw0rthy 
Indeed, with great power comes even greater responsibility.;)
You are absolutely right. It’s not just the initial use of the ORM – it’s the fact that others will come along later and fix bugs or build new features by re-using existing data access methods, which were not designed with the performance requirements of the new functions in mind.
An example: in a case management system, the customer pointed out that a menu item present on all pages should have its wording changed depending on whether or not the case had a team leader defined for it. At the requirements level, this seemed like a small change. The developer assigned to fix it chose to re-use a service method which retrieved the whole team, so that he could iterate over the team members’ roles to see if there was a team leader. We suddenly had something like 60 new queries being executed for every page rendered.
I admit that this is not just about the use of ORM – there’s a more general tension between re-use of functionality and conformance with non-functional requirements (performance, in this case). But I agree 100% with the observation that ORMs, which can yield very elegant results in the right hands, are a recipe for disaster in the wrong hands. You can’t tell by looking at the code, you have to look at the SQL that is being executed.
certainly what you are highlighting is a skill issue. Deeper understanding of database and SQL is very important along with ORM technology.
I had to laugh when I read this… because it’s true!
Spend 15mins on the Hibernate forums and you find that most people asking for help fill out a form like this:
Hi Hibernate,
My name is x. I have y experience with Java, which makes me underqualified for my job, and I lied during my interview because I figured I had seen it before, which makes it a resume bullet.
Anyway, I’m having a problem mapping this column to my database. (Which is in .5 normal form; that’s half of first normal form). I’ve also created an abstraction layer for Hibrenate. I’ve also forgot to include my sample code, a stack trace, but the important thing here is that you post code to solve my problem. I’m too busy learning other things that I should have known for my job to read the user manual, but to be fair, I’ll say I read it anyway.
Thanks!
-x
LOL… dat was really funny. Cld dat be rily true? My tots over this weekend was that de are people like this in virtually all works of life, n i rily wonder how people in the medical world manage issues like this. I 4sure know de are crappy doctors.
I also agree!
Many people use ORM and do not know about Persistence Context, Detached Objects, and so on. This creates a lot of trouble and bad usage of the framework.
This is why I would often recommend to use MyBatis instead of an ORM framework. It is very lightweight, easy and transparent to the developer. You still do write SQL, but it removes a lot of boilerplate code.
Nevertheless, ORM is awesome for many use cases (but needs experts who know what they do).
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
“Many people use ORM and do not know about Persistence Context, Detached Objects, and so on. This creates a lot of trouble and bad usage of the framework.”
Couldn’t agree more with your argument.
Pierre
I can’t help but think an ORDB is like order a car, and having it disassembled, delivered piece by piece through the letter box, and it then reassembles itself.
Why not get it delivered complete?
I have been using an ORM for two months from using a Data Mapper like Ibatis. My beef with it is that I can only make simple queries but when business logic gets a little bit complicated, I end up writing more than one call for for that using an ORM.
Honestly I do not like ORM. I have somewhat 3 uses of ORM:
First use, you have an object model. You say ‘persist’, and the ORM manage to do so, managing inheritence and everything in your object model in your database. Excepted from the simplest application, this is a performance and maintenance nightmare.
Second use, you have a real relationnal model in your database. You duplicate this exact model in your object model with relations and all (one to many etc etc). You use lazy loading and advenced features of ORM to teak performance and what is get from database. This is better than previous design, but still have problems. Most of the time like said here. You should not navigate in the object model at all. You should perform queries to get the data you need anyway. There is also encapsulation problem. The application layer is dependant of the exact structure of the database. No interface is defined.
Last use, ORM is used basically for mapping colums to fields with some type conversion. Nothing more. No joins, no lazy loading, no ORM cache. Instead of directly reading tables, you really perform queries to the database (idealy using views and stored procedures) and fetch only the results. You have a clear interface to communicate and don’t care anymore how the data is retrieved. The view or stored procedure take care of this. If the database model change, theses change are limited to the database. Not the application.
Honestly, this is the last model I like more. It is usually faster than the 2 other and you have clear separation of concerns. ORM performance and complex optimization concerning lazy loading and all simply disappear. What more? SQL is much more expressive than JAVA or HQL (or any other ORM DSL). You can perform joins, subqueries the way you like… A 5 line SQL query being often worth 50 or 100 line of application code.
Good points! The last model is similar to what i try to do when i have no control of who/how the data access code will be used.
Problem is that people use ORMed domain model without thinking about the database. They don’t realise that a call to the model can trigger many SQL calls.
Hi, I have been working with ORMs for years and I share your view.
Unless you study JPA or Hibernate properly and also think hard and try to write the code for it properly, which is not the case for majority of ordinary developers, it becomes a burden, an added layer of complexity in your applications.
I personally prefer myBatis as it does exactly what I expect it to do.
Forces people working with data access to learn SQL properly, but that is really the programming language which should be used for accessing data in relational databases. The main aim of ORM should be to reduce errors in code which is accessing data but it introduces too many new ‘hotspots’.
I am afraid that aversion towards SQL is the main point in ORM use and that we are going to stick with it for too long.
different angle which is quite important for thinking agree with @Ranjan here “Deeper understanding of database and SQL is very important along with ORM technology.
This problem is even compounded by the fact that now, you can bring that entity all the way to the jsf page with the new simplifications in Java EE 6 without any interception only to realise the model has not been fully loaded….ahem…
then u fully load the data before you reach the jsf page only to display a username….ahem
then you bring in C:foreach on that collection and u get hit with the LazyInitialization exception…dear..
I have just deployed two real world applications, one with DAOs and one without DAOs and I have learn’t my lessons.. Its easier to do the dirty tricks behind a DAO and return a DTO which results in loads of duplicate code but reliable than using an Entitymanager to load data in your presentation layer and think its quicker.. u waste more time hacking getter methods than actually writing any usefull business logic..
To be fair, this is true for any higher level paradigm in programming. How many programmers are left that could hack up an app in assembler to run in 64K. Those guys (and gals) no doubt complain about the bar as well.
The real trick is to lower the bar, while still making it fail-safe. This has been done numerous times in the past of course (with things like 4GLs), but gets ignored because most programmers gravitate towards technologies with more power than they can handle. It’s an industry of people perpetually shooting themselves in the foot.
Nice first post :-)
Paul.
It’s hard to disagree. Junior level developers who discover ORM feel senior until they have to open the box and tinker inside.
I use ORMs (Entity, netTiers, NHibernate depending on the needs) for the speed, reliability and freedom to focus more on functionality which can not be accomplished through boiler-plate code (which is what a code generating ORM does). The difference is, I’ve been doing this for a decade and understand the output by nature of coding the DAL by hand for so long.
ORM is only a starting point. You MUST understand the output and know how to analyze the implementation code used against it (querying, binding, etc).
IMHO, ORM works quite well when you have an Architect running the gen/re-gen AND performing ongoing analysis of how its being used. By finding those horror story examples like the above you learn that either:
A) The developer just doesn’t know how to use what has been provided (your fault, re-educate immediately)
or
B) The developer knows perfectly well how to use the architecture (service layer / biz objects) and his/her flailing is an indication you have not predicted all the use cases. At that point, adding indexes, relationships, constraints or writing something specialized like a performant Search method is necessary.
Just driving the nail home: A black box is cool for what it can do. It becomes a liability if you can not provision for those things it can’t.
Just an aside: I accelerated my Architectural understanding by generating ORM structures and learning how they worked. In most cases they represent (someone’s) best practices. Take advantage of that knowledge. Personally I find netTiers a great SOA generating ORM backed by stored procs. A great entry point for people new to ORM.
Amen brotha. While I used to be strongly on the ORM bandwagon, they’ve fallen out of favor for me. They are a solution looking for a problem. I found that they end up being more complicated, take more time to develop, and in the end are more costly than just developing a simple DAO layer. The moment your data model isnt modeled perfectly for the ORM, or you need to tune a query, the walls come crashing down.
Back in the day, they were supposed to make the data layer simpler, but time told that it wasn’t so. It was supposed to provide a level of isolation between your database and your code. You could switch databases or rearrange your data model while justodifying a few XML files. Who really does that? I’m in charge of about 200 developers and over 100 systems. Each and every one that used hibernate has had major issues, thus we no longer allow it’s use where I work.
This is a dearth in skill across the board. Not just with the use of ORMs. Mayb this dearth is more expensive when an ORM is misused by this symptomatic of a larger problem within our space.
I don’t like Orm, groovy SQL is good enough abstraction for me
I totally agree with you on the technical part. But you’re missing a major point here: ORM (as any other technology) is made mainly to reduce the cost of product development. And I’d disagree with Sean and say it does its job pretty darn well.
It’s obvious that you cannot compare hand-made designer shoes to mass-production slippers, made on conversion line by millions a day. It’s up to you, to either pay twelve hundred dollars for something good or get a pair for twelve bucks and be happy with it, as far as it serves its purpose.
Before ORM came around, the companies did not have a choice but to hire highly skilled, expensive developers to do the software. Now they can get less qualified people to do the same job at much lower cost. It’d be naive to expect the same quality, of course. But again, thank to ORM technology, we have that choice now.
[…] have mixed feelings regarding ORMs in general, but it does make your life easier sometimes. There is no shortage of […]
[…] http://www.caffeinatedcoder.com/does-it-make-sense-to-use-nhibernate-in-a-sproc-only-shop/ against https://n0tw0rthy.wordpress.com/2011/05/28/orms-hidden-cost/ for […]
[…] To drive these points home a little further, a quick look at the short posting at the following link should convince you of why using a straight-forward data-access-layer is a better bet for application development… https://n0tw0rthy.wordpress.com/2011/05/28/orms-hidden-cost/ […]