IBM developerWorks makes an unfair comparison between Ruby’s Active Record persistence component and Hibernate, a persistence framework for Java. It also compares Rails and Struts, but I’m not interested in that comparison (it’s easy to see why Rails wins there). On the Hibernate front, Active Record and Hibernate are beasts of a different nature. Active Record creates a sort of proxy for database tables by examining the database schema itself. This makes your database schema tightly coupled with your business objects (since there aren’t any, really). Rails, in turn, is tightly coupled with Active Record. What this means in practice is that if you have the ability to design a schema with the semantics that Rails prefers, you can get a whole lot done in no time.
Hibernate, which has all those nasty mapping documents (shown in the article) takes you longer to get up to speed (although you can save a lot of time using something like Xdoclet rather than writing your mapping files by hand), but if you’re working with a legacy database schema, this flexibility pays off in a big way. Hibernate can deal with just about any existing schema you could possibly imagine — even if it uses composite, natural keys or other byzantine practices of database design.
I’m not knocking the tight coupling that makes Ruby on Rails easy to roll out, but I do caution people that when comparing it to Hibernate, they’re comparing apples to oranges. Hibernate is built for maximum flexibility in dealing with legacy databases, Rails is built for speed of development when you own the whole stack (and generally are working from scratch).
Also, for the sake of comprehensiveness, it’s worth noting that Hibernate ships with a number of tools for code generation that enable you to generate the code for other layers from any layer of code that exists. In other words, you can generate a DB schema from mapping files, Java classes from mapping files, mapping files from a DB schema, and so on. This comes in really handy when you want do something like run tests against a clean database when you’re regression testing.
Unfair comparisons
IBM developerWorks makes an unfair comparison between Ruby’s Active Record persistence component and Hibernate, a persistence framework for Java. It also compares Rails and Struts, but I’m not interested in that comparison (it’s easy to see why Rails wins there). On the Hibernate front, Active Record and Hibernate are beasts of a different nature. Active Record creates a sort of proxy for database tables by examining the database schema itself. This makes your database schema tightly coupled with your business objects (since there aren’t any, really). Rails, in turn, is tightly coupled with Active Record. What this means in practice is that if you have the ability to design a schema with the semantics that Rails prefers, you can get a whole lot done in no time.
Hibernate, which has all those nasty mapping documents (shown in the article) takes you longer to get up to speed (although you can save a lot of time using something like Xdoclet rather than writing your mapping files by hand), but if you’re working with a legacy database schema, this flexibility pays off in a big way. Hibernate can deal with just about any existing schema you could possibly imagine — even if it uses composite, natural keys or other byzantine practices of database design.
I’m not knocking the tight coupling that makes Ruby on Rails easy to roll out, but I do caution people that when comparing it to Hibernate, they’re comparing apples to oranges. Hibernate is built for maximum flexibility in dealing with legacy databases, Rails is built for speed of development when you own the whole stack (and generally are working from scratch).
Also, for the sake of comprehensiveness, it’s worth noting that Hibernate ships with a number of tools for code generation that enable you to generate the code for other layers from any layer of code that exists. In other words, you can generate a DB schema from mapping files, Java classes from mapping files, mapping files from a DB schema, and so on. This comes in really handy when you want do something like run tests against a clean database when you’re regression testing.
Commentary
Previous post
So many blogging tools, so little timeNext post
Torture as policy