Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2569 posts at DZone. You can read more from them at their website. View Full User Profile

The ORM Debate: Experts Weigh In

10.20.2009
| 12013 views |
  • submit to reddit

A lot of controversy has been generated recently over blog posts "ORMs are a thing of the past" and (the more poetically titled) "A Farewell to ORMs".  They have been fueling debates over the merits and shortfalls of ORMs.  DZone contacted some developers who have worked with ORMs to weigh in on this issue.

Is the ORM becoming obsolete?  Is it still a necessary tool?  Share your stance in the comment box below.
 
Jesse Davis, a Senior Engineering Manager at DataDirect, is a JDBC expert and deeply understands the uses of ORM.  "ORM's were created because they're easy.  It exposes people to the SQL language," Davis said in an interview with DZone.  He says that people will always run into more problems as they add more layers of abstraction on top of boilerplate code.  He admits that some of the things in the anti-ORM blogs are true, but that ORMs are far from a thing of the past.  "Be aware of why you need the technology," he says. 

Davis says more about ORMs in his interview with DZone's Nitin Bharti:

"With the ORM, the programming style is just different. So it's mostly a matter of taste. Some would argue that it's a matter of power, but I think it's mostly taste. And when you come down to it, the ORM model is an excellent model when designing for very complex systems.

But in order to use an ORM, you're going to have to live with some sacrifices. You're going to have to sacrifice some performance because again, an ORM is useless without data connectivity. And so the ORM is built on top of the driver. Again you have the ability and the query language - I'll take JPQL for instance. It's an object-based query language. So you can query your objects but when that object model gets down to the wire level, it still has to be translated into a SQL statement before going into the database.  And so you have to live with giving up a little bit of your control of your SQL statements in order to use the more ease-of-use features of an ORM model."

Emmanuel Bernard, a JBoss lead developer on the Hibernate team, also talked to DZone about ORMs and had this to say:

"Let's start with the fundamentals, RDBMS are not going anywhere anytime soon. All the hype about NoSQL is just the expression of niche markets where RDBMS have their limits and where better tools can be found.
While Facebook, twitter and the like might find relational databases limiting due to scalability issues, remember that 99.999% of applications out there do not need to scale anywhere near a hundredth of what these sites are experiencing.

Now, provided that SQL is not going anywhere, ORMs are not going anywhere. Thus far, they have proven to be the most effective way to access your relational database 95% of the time both from a performance point of view and from a code simplification PoV. Of course, like any tools, don't use it where it does not make sense. In some applications, plain SQL is easier.

To answer specific questions raised by "ORM's are a thing of the past":
 - Correct, there is a learning curve to ORMs but standardization like JPA has increased the overall population knowledge. Plus, in most teams, one person knowledgeable in SQL and ORMs is enough to counter-balance most ORM problem or misuse.
 - State transfer and management is a complex topic and LazyInitializationException is a symptom of this. State management frameworks have grown out of this problem like Seam or JSR-299 CDI by looking at the bigger picture rather than blame the messenger. They are here to globally address the problem of state management and state transfer. You won't get any LazyInitializationException if you play within their paradigms.

ORM is about updating your database and querying your data automatically and in an optimized way for 95% of your use cases.
For the 5% remaining, go with raw SQL. Your mileage may vary depending on the ORM, but if for example you are massively inserting / updating data, you are usually best done in plain SQL rather than with a traditional ORM. But it's just common sense vs abuse of a tool."

Bernard said the alternative to using ORM was to "Painfully write all your SQL statements and be beaten down by your DBA for characterized query inefficiency. Instead of having optimized queries 95% of the time and work with your SQL expert for 5% of them, you will have to rely on him for 40% of your queries."

What is your opinion of ORMs?  Are they going to stick around or will they soon become extinct?  We want your position.
AttachmentSize
jessedavis.jpg8.85 KB
Tags:

Comments

Florian Kammermann replied on Tue, 2009/10/20 - 12:22pm

I agree that in the moment an RDBMS is the only way to persist and query complex data-structure, but we know for which tradeoff. Object-oriented-databases would be much more easy, but what do you make when the application is end of life and another application must work with the object-database. I'm not expert here, but in this case I prefer the loose coupling of SQL, cause I know its the common case and solutions are available. The real life shows that data outlives normally the applications, so you must have a good API to plug another application to your data.

The big value of RDBMS is, that you have this standard  SQL. And thousands of clients and workers are available to use it.

The tradeoff of RDBMS in the OO-World is, that it costs the projects to much money, for the added value.

The best thing what I can imagine, would be an API like SQL for object-oriented-databases. An API which fits into the OO-World, but which has the same decoupling and standardization-level  of SQL.

Ibrahim Levent replied on Wed, 2009/10/21 - 12:07am

Most of the projects using >25 database tables would need a persistence solution.

John O'Hanley replied on Tue, 2009/10/20 - 4:24pm

I think ORM is a mistake, and I think it fails in the goal of making persistence easier.

Initially, ORM purported to solve a problem that didn't exist: the 'problem' of abstracting away SQL. Why would I want to do that? Why would I want to abandon the domain-specific language developed over many years, that's widely understood, and robust? Ostensibly the answer was "because SQL is complex".  That's a highly debatable assertion, and the solution in this case (ORM) causes many more headaches than it purportedly solves.

Tomi Tuomainen replied on Wed, 2009/10/21 - 12:58am

ORM solution needs to be simple to be productive. It should be easier and faster to use compared to hand-written SQL and ResultSet extraction. Current JPA tools are not.

I just blogged about this too: http://blog.devtrain.fi/2009/10/18/kauklahti-making-orm-simple/.

I wrote this simple library Kauklahti that basically just extends Spring JdbcTemplate and to support full CRUD generation and simple joins and collections. It is really not full-blown ORM tool with sessions, caches and stuff. I consider it as an automation of writing SQL and extracting ResultSets.  

So far this solution has saved some coding time in our current project. And of course, I'd rather "rather write code that writes code, than write code" :)

Gervais Blaise replied on Wed, 2009/10/21 - 2:43am

I'm not an experienced developper (with ORM at least). I started using Hibernate since one year and I discovered a powerfull tool who make me more productive. But when I have to map more complex relations I lost more time than writing plain SQL with Jdbc.

Hopefully, I'm using the MVC paradigm and I can mix Hibernate and Jdbc daos objects. I think this is a good solution.

When I discuss with other developpers, I hear that the most commons problem is about "how to retrieve an object with many relations without retrieving all the schema"and in this case Hibernate (or other ORM) are the best tool for doing that.

Fab Mars replied on Wed, 2009/10/21 - 6:35am

I totally agree with Emmanuel Bernard.

 

Now my personal opinion:

Once you've worked on a big project with a big database, and a big team, requirements changing back and forth, and keepping in mind you'll have to support the code and possibly huge requests afterwards, you appreciate ORMs.

I tend to advise the use of ORMs for the CRUD parts of a given application and SQL for massive and quick front-end searches. Typical example: a tour-operator information system.

Now, for your study project or home/family project this mightbe overkill to use ORMs at all. Just adapt your behavior to the conditions, like when you're driving...

Tomi Tuomainen replied on Wed, 2009/10/21 - 7:16am in response to: Fab Mars

My experience is that especially in big projects ORM problems become a bottleneck. "Hello world" and simple table mappings work fine. But complex domain model mapped to complex database is killing productivity and causing often serious performance problems. 

I don't see any reason, why making changes (adding column etc.) would be easier with ORM library. In addition to JavaBean and SQL you have to maintain annotations/xml and the mapping strategy. Unless you have a really a good table/xml-generator, that will do all the changes in one click (haven't seen one though).

George Farmer replied on Wed, 2009/10/21 - 2:08pm in response to: Fab Mars

This dual approach just shows how inadaquite the ORM technology is. Another thing is that for a big project the only approach that works efficiently is to generate objects from the database, regardless of how much it may offend fans of rich domain model.

Fadzlan Bin Yahya replied on Wed, 2009/10/21 - 6:50pm in response to: Tomi Tuomainen

I believe its just a matter of compromise. In order to have your full cake (eg. cache, state management), you have to deal with the extra fats (complexity, etc).

Mark Unknown replied on Wed, 2009/10/21 - 8:20pm in response to: John O'Hanley

 I think ORM is a mistake, and I think it fails in the goal of making persistence easier.

 I don't have to "think". I know. I have hand coded SQL.  I can find "by Interface" with an ORM. With raw sql i have to write sql for each table.  I can persist a tree with a single Save statement versus multiple sql statements.

Initially, ORM purported to solve a problem that didn't exist: the 'problem' of abstracting away SQL. 

 It is more of an inconvenience than a problem.

Why would I want to do that?

 

select e.id. e.person.lastName  from Employee as e

vs

select e.id p.last_name from tbl_employee e, p.tbl_person where e.person_id = p.id

or (if you, GFB, used SSN as the key

 select e.id p.last_name from tbl_employee e, p.tbl_person where e.ssn = p.ssn

The good thing about using an ORM is that you could change the key in the db and just fix the mapping and VIOLA! every place that uses it is GTG. (ok, you MIGHT have to change the save method a wee bit) 

 Why would I want to abandon the domain-specific language

 Depending on the ORM, you are NOT abandoning it.

 

 

 

Mark Unknown replied on Wed, 2009/10/21 - 8:31pm in response to: Gervais Blaise

gervais.b - this is the problem with anything. If you learn without a mentor, you will have to make all the mistakes yourself while you learn and also run the risk of getting stuck.  In your case it is ORM. For others it is MS Access, for instance.  I just joined a team that has VERY smart people on it. But guess what? They were in the same boat you are.

Can complex relations be tough in an ORM? Sometimes. But it takes me less time than handcoding SQL.

Mark Unknown replied on Wed, 2009/10/21 - 8:37pm in response to: Fab Mars

I have an app that allows the users to create complex search queries ... and I use HQL for it. Tons simpler and easier to read than what i would have had to do with SQL.  Additionally, for massive quick-front end queries I would suggest using Hibernate Search or Compass (if you are using Hibernate).

Mark Unknown replied on Wed, 2009/10/21 - 8:51pm in response to: Tomi Tuomainen

My experience is that especially in big projects ORM problems become a bottleneck. "Hello world" and simple table mappings work fine. But complex domain model mapped to complex database is killing productivity and causing often serious performance problems.

 You need to work with better people and/or a better ORM and/or a better database. I work with Hibernate on a complex project and don't have this problem. I have two people who have never done ORM before. They are picking it right up AND are doing complex object models.

don't see any reason, why making changes (adding column etc.) would be easier with ORM library.

 If you are using "domain" objects...

For an ORM .. Add column to mapping and db. If you are only selecting fields in some queries you will need to add it there.

For SQL - Add to database, to ALL selects, updates and inserts and to the code that creates the object.

How about if you change the column name in the database? LOL I have been on  project where we switched from Sybase to DB2. Each had their own naming conventions. We were done with our changes in an hour(?). We were done before the DBA created their DDL. (Not sure why they had to hand code it).

 

Mark Unknown replied on Wed, 2009/10/21 - 8:57pm in response to: George Farmer

This dual approach just shows how inadaquite the ORM technology is

 No. It shoulds that people either just like SQL or are not that familiar with ORM or other possible solutions.

Another thing is that for a big project the only approach that works efficiently is to generate objects from the database

 Have you EVER used an ORM? Which one? I use Hibernate. I don't need to do this. I have reversed engineered from a database with Hibernate(Really was Seam) and NHibernate. I doubt I will do it again.  Field naming,  Field type, Class naming and Class structure were a mess. Maybe there are better tools now.

Tomi Tuomainen replied on Thu, 2009/10/22 - 4:07am in response to: Mark Unknown

You need to work with better people and/or a better ORM and/or a better database. I work with Hibernate on a complex project and don't have this problem. I have two people who have never done ORM before. They are picking it right up AND are doing complex object models.

I work with people over 5 or 10 years experience with Java. I've fixed Hibernate problems created by our developers and developers of a customer and other vendors. I am the guy who is called when everything fails. And I will fix it.

We usually have 100-200 tables per application. And we get things right and running in production. But the problem is that productivity with Hibernate sucks. I face same problems with every project. And I also myself struggle with correct mapping strategies in every project.

Maybe we all in Finland are just crappy coders. But in recent projects without Hibernate, things are so much easier. We have walked the path from EJB 1.0 to Hibernate (JPA) and after all JDBC with Spring is the most productive solution. For SQL automation we have recently started using this Kauklahti library.

For SQL - Add to database, to ALL selects, updates and inserts and to the code that creates the object.

Ok, my SQL for one table is usually in one DAO, so adding column to all queries would take about 30 seconds. Even with ORM, you probably still have reports and custom queries that need to be modified (or then your reporting needs and database are really simple).This is not an issue justifying ORM. But total cost of bad ORM solution is not in seconds, it is in weeks or months.

Gervais Blaise replied on Thu, 2009/10/22 - 2:10am in response to: Mark Unknown

Mark - As you said, I learn without a mentor. But I learn alone because it seems that "hibernate professionnals" don't want to spend time for my questions. Of course there are many forums but someone who know my database schema can respond better and more quickly than a lot of peoples on a forum.

Can complex relations be tough in an ORM? Sometimes. But it takes me less time than handcoding SQL.

I hope to write complex relation mapping in less times than plain SQL but actually.. it is just a dream.

Developer Dude replied on Fri, 2009/10/23 - 11:25am

My opinion is: beware of posted *opinions* that assert "'X' is dead", or "'X' is obsolete", or "'X' is a thing of the past". Can you say 'troll'?

At best these kinds of opinions are uninformed, narrow and shallow. Not that they don't make some good points, but the conclusions are usually completely wrong.

The right tool for the right job. ORMs work in some use cases and not in others. I have seen cases where ORMs get in the way, and cases where they increase productivity. That is what we get paid for - to make the decisions about what tools to use, how to use them, and when. Making blanket statements about mainstream popular tools shows a lack of knowledge and discernment.

And just to be clear, no I am not a Hibernate fanboy. I've had some exposure to it, I've seen it used properly and totally misused. I prefer iBatis for the kinds of apps I write and my style of coding. Whether one is better than the other depends on the use case.

Lukas Eder replied on Sat, 2013/09/07 - 4:36am

ORMs will always stay around, as people will always want to leverage a tool that makes repetitive CRUD easy to perform. But ORMs will always be criticised as well, as they do not solve all problems. Instead they create new ones.

One domain that has been neglected by many types of libraries is the fact that some (yet, not all) developers wish to write embedded SQL inside their host language. .NET's LINQ-to-SQL is an attempt into that direction, although LINQ-to-SQL is pretty far from actual SQL.

Java has jOOQ, which models a lot of complex SQL constructs as an internal DSL in Java.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.