Debates flare on the right level of abstraction over ORM and JDBC
- Share
-
- |
Read later
My Reading List
A heated debate started a few weeks ago initiated by members of the Hibernate team, arguing that using an abstraction framework on top of an ORM is a bad idea, citing Spring's HibernateTemplate as a specific example. The argument was that portability across ORMs is not a realistic need, and using it is dangerous and can be misleading. The resulting debate on the blog entries thread saw Spring users arguing that HibernateTemplate is not about hiding Hibernate but instead about removing boiler plate code, providing more control, and providing a useful exception mapping hierarchy (useful if you're working with more than one datasource). The Hibernate team argued that most of the boilerplate code reductions were eliminated in Hibernate 3, the need for unified exception hierarchy isn't important, and that there is "not a single" usecase that would require HibernateTemplate.
Since then. Solomon Duskis blogged an additional usecase - separating xml configuration (for query caching) from different parts of the app - in this case runtime vs. administrative. Providing a lucid last work, Shay Banon agreed with the Hibernate team but also blogged yesterday an educational look at the historical needs for HibernateTemplate while mentioning that even with Hibernate 3, Springs abstraction handles of transactions and session context for non JTA code as well as providing slight code simplification.
Still on the theme of abstractions for data access, Brian McCallister wrote a survey with code examples of sql-centric convenience frameworks over JDBC. A quick summary:
Not speaking for floyd, I do not think that he stated the opposite. What we learned from the past years, is that a relational model is currently the de-facto way to represent a persistent, report aware model. Most system, or environments are aimed and ease the usage of such a model. The main question that remains is how do we simplify the relational model usage within our application. It basically ranges from using thin layers on top of our relational model (Active Record or Jdbc type), having an ORM framework, or going with the object oriented memory clustered model with an optional rational persistent model (like GigaSpaces provides).
Why? With proper ORM tools, or Active Record aware ones, you still have the problem of exponential joins that cross multiple database tables (assuming it is what you meant). What I mean is: the same problems you face with a complex relational model, are the problems that you will face with a complex domain model. The same rule of lowering your relational model level of integrity in order to have better performance apply when modeling a proper domain model. The nice thing about ORM tools is that they allow you to maintain a more "complex" domain model, while having a more relaxed relational model.
That is funny, cause most of the folks that I know who work on ORM frameworks always say: "use the best tool for the job". It might be a matter of marketing, since you do not want to sound like a cheesy salesman, but I do believe that they mean it.
Of-course you can model complex systems in a procedural language. Hell, I built more than my share of complex systems in C (though, I agree, you can get many of the OO features in C as well using virtual pointers). But thinking of building a complex system now (I judge a complex system in having more then 5 entities in the domain model, with relationships between them), using a procedural language scares the shit out of me. I basically would find myself doing complex hacks in C (for example) in order to give the feeling of a rich domain model. I would much prefer working in a language that would have inheritance, polymorphism built into it, then trying to simulate it.
Don't get me wrong, I am the type of person that strongly believes in the "right tool for the right job". And I agree that the ability to define or understand such a statement is not a simple thing to do. But going all the way and saying something like that about OO, I think is getting somewhat overboard.
For delaing with large volumes of data, I kind of like declarative set operations, the kind that things like SQL do very nicely.
Problems with no mutable state, stream processing (a la sed), mathematical modeling, etc. You can use "objects" to solve any problem you want, but the fact that you have "local global" state and operations limited to working on that state is of no help for a lot of things, such as those I just mentioned.
Rather than try to enumerate things, think about problems where you use SQL, HTML, XML, XSLT, sed, or sh. All those are pretty common :-)
Note that this use case (ie caching all queries) is most likely a good way to slow down your application :-) Very few queries benefit from caching.
Oh dear. Parents didn't like you or something?
No. ORM is based on the assumption that you have Java objects in application space and you have a relational datastore and want a mechanism for transforming between the two because you cant change either end. It is not recommended for all situations.
13 comments
Since then. Solomon Duskis blogged an additional usecase - separating xml configuration (for query caching) from different parts of the app - in this case runtime vs. administrative. Providing a lucid last work, Shay Banon agreed with the Hibernate team but also blogged yesterday an educational look at the historical needs for HibernateTemplate while mentioning that even with Hibernate 3, Springs abstraction handles of transactions and session context for non JTA code as well as providing slight code simplification.
Still on the theme of abstractions for data access, Brian McCallister wrote a survey with code examples of sql-centric convenience frameworks over JDBC. A quick summary:
- RIFE uses a builder approach to sql statements which is very useful for dynamic query generation.
- jDBI is suitable with direct SQL and static statements and provides more control on how queries will be executed.
- Apache DbUtils "is a short-and-sweet tool which provides even less high-level functionality, but is extremely well tested and quite flexible".
- Spring provides a few convenience API's, mostly centered around the
JdbcTemplate,which focuses on making the common cases easy and portable. - "JDBC 4 (part of JDK 1.6) will include a spiffy looking convenience API that looks like an annotation based SQL-J."
- IBatis
Community comments
ORM is wierd
by
j c
Posted
Re: ORM is wierd
by
Floyd Marinescu
Posted
Re: ORM is wierd
by
Brian McCallister
Posted
Re: ORM is wierd
by
Shay Banon
Posted
Re: ORM is wierd
by
karan malhi
Posted
Re: ORM is wierd
by
Brian McCallister
Posted
Re: ORM is wierd
by
j c
Posted
Re: ORM is wierd
by
Javier Pavier
Posted
Re: ORM is wierd
by
Peter Monks
Posted
Re: ORM is wierd
by
j c
Posted
Caching all queries: bad
by
Emmanuel Bernard
Posted
Re: Caching all queries: bad
by
Solomon Duskis
Posted
Hibernate
by
Tiberiu Fustos
Posted
ORM is wierd
by
j c
I like hibernate etc but I have to admit, ORM is one of those tools that really isnt based on any real theory of storing data. Its lipstick for the pig. Why cant they come up with something better? When objects were "hard to store" noone blamed the objects they blamed the DB.
If all shops worked like ORM tool shops we would all be writing massive amounts of code to prove assembly is cool or fortran rocks.
There is thankfully a self limiting principle in software in that the longer you work on solving a certain problem the more likely you dont understand the problem or you created it yourself to amuse yourself instead of getting more important work done.
If ORM never existed software wouldnt be much better or worse than it is right now. Its not curing cancer.
If all shops worked like ORM tool shops we would all be writing massive amounts of code to prove assembly is cool or fortran rocks.
There is thankfully a self limiting principle in software in that the longer you work on solving a certain problem the more likely you dont understand the problem or you created it yourself to amuse yourself instead of getting more important work done.
If ORM never existed software wouldnt be much better or worse than it is right now. Its not curing cancer.
Re: ORM is wierd
by
Floyd Marinescu
If ORM never existed software wouldnt be much better or worse than it is right now. Its not curing cancer.j c (what's your name?), I can't imagine not having ORM to ease the complexity of persistence when you're working with a medium to large domain model. In some ways, questioning the value of ORM is equivalent to questioning the value of OO. Can you say that object orientation is not a better way to model complexity in software development than procedural?
Re: ORM is wierd
by
Brian McCallister
Floyd,
I think you are drawing an analogy which is incorrect. Your statement can be flipped and remain equally true -- "I can't imagine not having relational systems to ease the complexity of persistence when you're working with a medium to large domain model."
Objects provide a great way of managing mutable state and organizing functions, yes. They kind of suck for dealing with large volumes of said state :-)
Transparent O/R mapping is great for certain classes of problems, but there is a tendency to treat it like a golden hammer, and not very good understanding of where it doesn't apply well.
Prominent folks working on a variety of popular frameworks tend to exacerbate this by saying their toolkits are always the best solution.
Also, regarding "Can you say that object orientation is not a better way to model complexity in software development than procedural?" -- yes, I can say that, depending on the problem at hand :-)
I think you are drawing an analogy which is incorrect. Your statement can be flipped and remain equally true -- "I can't imagine not having relational systems to ease the complexity of persistence when you're working with a medium to large domain model."
Objects provide a great way of managing mutable state and organizing functions, yes. They kind of suck for dealing with large volumes of said state :-)
Transparent O/R mapping is great for certain classes of problems, but there is a tendency to treat it like a golden hammer, and not very good understanding of where it doesn't apply well.
Prominent folks working on a variety of popular frameworks tend to exacerbate this by saying their toolkits are always the best solution.
Also, regarding "Can you say that object orientation is not a better way to model complexity in software development than procedural?" -- yes, I can say that, depending on the problem at hand :-)
Re: ORM is wierd
by
Shay Banon
I think you are drawing an analogy which is incorrect. Your statement can be flipped and remain equally true -- "I can't imagine not having relational systems to ease the complexity of persistence when you're working with a medium to large domain model."
Not speaking for floyd, I do not think that he stated the opposite. What we learned from the past years, is that a relational model is currently the de-facto way to represent a persistent, report aware model. Most system, or environments are aimed and ease the usage of such a model. The main question that remains is how do we simplify the relational model usage within our application. It basically ranges from using thin layers on top of our relational model (Active Record or Jdbc type), having an ORM framework, or going with the object oriented memory clustered model with an optional rational persistent model (like GigaSpaces provides).
Objects provide a great way of managing mutable state and organizing functions, yes. They kind of suck for dealing with large volumes of said state :-)
Why? With proper ORM tools, or Active Record aware ones, you still have the problem of exponential joins that cross multiple database tables (assuming it is what you meant). What I mean is: the same problems you face with a complex relational model, are the problems that you will face with a complex domain model. The same rule of lowering your relational model level of integrity in order to have better performance apply when modeling a proper domain model. The nice thing about ORM tools is that they allow you to maintain a more "complex" domain model, while having a more relaxed relational model.
Prominent folks working on a variety of popular frameworks tend to exacerbate this by saying their toolkits are always the best solution.
That is funny, cause most of the folks that I know who work on ORM frameworks always say: "use the best tool for the job". It might be a matter of marketing, since you do not want to sound like a cheesy salesman, but I do believe that they mean it.
Also, regarding "Can you say that object orientation is not a better way to model complexity in software development than procedural?" -- yes, I can say that, depending on the problem at hand :-)
Of-course you can model complex systems in a procedural language. Hell, I built more than my share of complex systems in C (though, I agree, you can get many of the OO features in C as well using virtual pointers). But thinking of building a complex system now (I judge a complex system in having more then 5 entities in the domain model, with relationships between them), using a procedural language scares the shit out of me. I basically would find myself doing complex hacks in C (for example) in order to give the feeling of a rich domain model. I would much prefer working in a language that would have inheritance, polymorphism built into it, then trying to simulate it.
Don't get me wrong, I am the type of person that strongly believes in the "right tool for the right job". And I agree that the ability to define or understand such a statement is not a simple thing to do. But going all the way and saying something like that about OO, I think is getting somewhat overboard.
Re: ORM is wierd
by
karan malhi
Brian,
Why do they suck? Instead of objects what would you have preferred?
Can you please explain what could be the problem for which object-orientation is not well suited?
Objects provide a great way of managing mutable state and organizing functions, yes. They kind of suck for dealing with large volumes of said state :-)
Why do they suck? Instead of objects what would you have preferred?
Also, regarding "Can you say that object orientation is not a better way to model complexity in software development than procedural?" -- yes, I can say that, depending on the problem at hand :-)
Can you please explain what could be the problem for which object-orientation is not well suited?
Re: ORM is wierd
by
Brian McCallister
Why do they suck? Instead of objects what would you have preferred?
For delaing with large volumes of data, I kind of like declarative set operations, the kind that things like SQL do very nicely.
Can you please explain what could be the problem for which object-orientation is not well suited?
Problems with no mutable state, stream processing (a la sed), mathematical modeling, etc. You can use "objects" to solve any problem you want, but the fact that you have "local global" state and operations limited to working on that state is of no help for a lot of things, such as those I just mentioned.
Rather than try to enumerate things, think about problems where you use SQL, HTML, XML, XSLT, sed, or sh. All those are pretty common :-)
Re: ORM is wierd
by
Peter Monks
"There is thankfully a self limiting principle in software in that the longer you work on solving a certain problem the more likely you dont understand the problem or you created it yourself to amuse yourself instead of getting more important work done."
Superb! This is going up on my quotes board! :-))
Caching all queries: bad
by
Emmanuel Bernard
Since then. Solomon Duskis blogged an additional usecase - separating xml configuration (for query caching) from different parts of the app - in this case runtime vs. administrative.
Note that this use case (ie caching all queries) is most likely a good way to slow down your application :-) Very few queries benefit from caching.
Re: Caching all queries: bad
by
Solomon Duskis
I'm not caching all queries... I'm caching all queries within a specific DAO. The specific DAOs have queries like "select * from LookupObject" (which are actually performed via findAll), and "select * from CommonlyLookedUpDomainObject where logicalCode=?"
Perhaps my specific case includes of the "few" queries that benefit from caching. Perhaps there might be a better way to do this via hibernate proper.
I don't cache ALL of my queries, but I did find it useful to cache all queries coming in a specific set of DAOs.
Perhaps my specific case includes of the "few" queries that benefit from caching. Perhaps there might be a better way to do this via hibernate proper.
I don't cache ALL of my queries, but I did find it useful to cache all queries coming in a specific set of DAOs.
Re: ORM is wierd
by
j c
the names Java Coder.
Floyd, that was kind of my point. Because we all understand the benefits of OO in the application space. There is a huge assumption we are making that its the best model for storage or that somehow we have to make round peg fit square hole come hell or high water.
Ive sat through enough sales pitches based on impedance mismatch from every JDO and ORM and OODBMS vendor that exists and Ive seen large large domain models borne of the optimism that it can be done to see 250 dollar an hour contractors whither and pale when the whole thing came crashing down on their heads when the rubber hit the road.
Im not saying it cant be done. But Im saying we have been down this path for years and it still is highly refutable that this is the right approach. And SQL to some degree was based on an analysis of storing sets.
ORM is based on the assumption that objects are right for everything.
Of course OO is the best way to go. But if it was so TOTALLY true then much of it would be self evident and our systems would be light years better than they were before
They are not generally even if we "like the way the code looks" better.
Floyd, that was kind of my point. Because we all understand the benefits of OO in the application space. There is a huge assumption we are making that its the best model for storage or that somehow we have to make round peg fit square hole come hell or high water.
Ive sat through enough sales pitches based on impedance mismatch from every JDO and ORM and OODBMS vendor that exists and Ive seen large large domain models borne of the optimism that it can be done to see 250 dollar an hour contractors whither and pale when the whole thing came crashing down on their heads when the rubber hit the road.
Im not saying it cant be done. But Im saying we have been down this path for years and it still is highly refutable that this is the right approach. And SQL to some degree was based on an analysis of storing sets.
ORM is based on the assumption that objects are right for everything.
Of course OO is the best way to go. But if it was so TOTALLY true then much of it would be self evident and our systems would be light years better than they were before
They are not generally even if we "like the way the code looks" better.
Re: ORM is wierd
by
Javier Pavier
the names Java Coder.
Oh dear. Parents didn't like you or something?
ORM is based on the assumption that objects are right for everything.
No. ORM is based on the assumption that you have Java objects in application space and you have a relational datastore and want a mechanism for transforming between the two because you cant change either end. It is not recommended for all situations.
Hibernate
by
Tiberiu Fustos
I am usually very careful not to fall into a "conspiration theory" trap - but I think all this fuss is just about Hibernate/JBoss to question the need for Spring - while pushing JBoss's own IoC container. Fact is, Spring has made massive inroads in enterprise application development especially because it provided a nice level of abstraction together with clear guidelines of application architecture by being non-intrusive and promoting best practices for all the different components that it integrates.
I agree that you don't change ORM tools that often, but in my company for example we have changed an app server for an application using SSH (Struts/Spring/Hibernate) from a commercial app server to JBoss in 3 days. And we could swap the app server again if needed...This wouldn't have been possible if we'd start using Jboss IoC for example. While we are big Open Source fans and users, and I think the contribution of Hibernate and JBoss to the IT space is significant (and made us more efficient with less license costs), one thing that is happening now is basically setting the field for the next battle: the next winner of the JEE app server space - now several big vendors have their own Open Source app server (Sun - Glassfish, IBM - Geronimo etc.) - so it's even more important to have a neutral layer like Spring, providing some investment protection.
I agree that you don't change ORM tools that often, but in my company for example we have changed an app server for an application using SSH (Struts/Spring/Hibernate) from a commercial app server to JBoss in 3 days. And we could swap the app server again if needed...This wouldn't have been possible if we'd start using Jboss IoC for example. While we are big Open Source fans and users, and I think the contribution of Hibernate and JBoss to the IT space is significant (and made us more efficient with less license costs), one thing that is happening now is basically setting the field for the next battle: the next winner of the JEE app server space - now several big vendors have their own Open Source app server (Sun - Glassfish, IBM - Geronimo etc.) - so it's even more important to have a neutral layer like Spring, providing some investment protection.
Educational Content
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think