Grails vs Rails comparison
While following some of the Grails and Rails tutorials (Grails: The Definitive Guide to Grails. RoR: Creating a weblog in 15 minutes) I noticed a big difference on how they approach development. Consequently, I started a thread (Dynamic Domain classes) on the Grails user mailing list to confirm. What I found, thanks to Tim Pidgen, was that Grails is intentionally domain-centric (ie model-centric) whereas Rails is more database-centric. What's the difference? With Grails you modify the domain classes (models) and the database is updated automatically. So properties are explicitly defined in the Grails domain classes; no database modification. Conversely, with Rails you create your "empty" model class and after you modify the database (add new fields to a table) you can just refresh the page; no need to add variables to your models.
Not sure either one is right or wrong; just wanted to point out the differences because it is a pretty significant difference.
9 comments:
I wonder how east Grails let's you behave the same way that Rails does. My inner database geek cringes a bit at the thought of giving up control of my db column definitions. I think this is mainly because I've yet to see a model-centric way that worked the way I my mind thought. Granted I guess I still think like a db admin. Maybe I'm too old school...
I have one big issue with the model that Grails uses, or at least with the lack of support for more of a DB-centric view.
I see Groovy and Grails as ways to greatly enhance productivity on a Java stack. OK, so what about the bazillion Java applications in production, that already have databases filled with live data? I think that is going to be the bulk of Groovy development. Sorry Graeme and Co., but having done both I would rather do green-field development in Rails for all but the largest apps.
If you accept my thoughts so far, that most Grails apps will be on top of an existing, live database, then how would you want to manage updates? I submit that the Rails migrations model is much more appropriate, I doubt too many architects are going to want to trust schema updates on live data to Hibernate's magic.
I completely agree with you both. In fact the response I received over the mailing list was focused on new development and not retrofitting to legacy systems, which I would believe would be a majority of the cases.
I still think it has enough benefits to at least consider it as an option and would probably definitely use it for new development.
Grails (more exactly GORM) supports non-conventional mappings for database columns, its not that hard to accommodate a legacy db into a modern Grails app. Have a look at Jason Rudolph's blog and on the Grails site =)
You guys seem to imply that, because it uses a database centric design, Rails works easily and well with existing databases.
Nothing could be further from the truth. No ORM, not ActiveRecord or GORM excel in this area. Your best bet is hand written SQL and business transaction scripts, because that's most likely what the legacy database was designed for.
That said, for existing databases I actually would give the win to Groovy for the following reasons:
* JDBC has better support overall for databases, including procs, odd types, and cursors.
* Hibernate has better support for arbitrary data models --it's not easy to get right, but it's more likely to work better.
* Groovy has better raw SQL APIs. Ruby's SQL APIs suck IMHO.
I'm saying this as a full time Ruby developer, Java developer of 10 years and the author of a fairly popular persistence framework.
Just my $0.02
Cheers!
Reading post here I get the sense tha t folks think that Grails cannot use existing legacy databases, nothing could be futher from the truth. It in fact does this really well look up "static mapping = {" in grails and you will find that custom legacy mappings can be defined.
I had no problem linking Grails to a legacy database. It's a little work, but not painful. Just the GORM database mapping, which is to be expected.
With Rails you can do the same sort of thing, basically mapping the database to the convention.
The problem with legacy databases with Rails or Grails is that Rails and Grails both expect a convention to be followed, and you'd be real lucky to stumble upon a database that fits that convention. So just push, pull, or drag, and you're in business.
Some people should really try the newer versions of ECLIPSE that's out - the one that comes with the Web Tools Platform. It easy to configure server profiles and when there are changes in the classpath, eclipse will automatically restart tomcat.
this kind of blog always useful for blog readers, it helps people during research. your post is one of the same for blog readers.
Post a Comment