Tracking change and innovation in the enterprise software development community
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
Posted by Floyd Marinescu on Aug 12, 2006 08:58 PM
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.
JdbcTemplate, which focuses on making the common cases easy and portable.Podcast download: An interview with Dmitry Sklyut on OSGi
Hibernate without Database Bottlenecks
The Agile Business Analyst: Skills and Techniques needed for Agile
Introducing Project Zero: Building RESTful services for your Web application
Scaling a Massively Multi-player Server Casestudy: Terracotta on SmartFoxServer
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 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?
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."
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.
Brian,
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?
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 :-)
"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! :-))
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.
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.
Thanks for the feedback!
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.
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.
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.
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
13 comments
Reply