Discussions

News: Grails + EJB Domain Models Step-by-Step

  1. Grails + EJB Domain Models Step-by-Step (5 messages)

    InfoQ has posted "Grails + EJB Domain Models Step-by-Step," an article by Jason Rudolph. This article walks through creating a simple EJB3 domain model (employees and their computers), and then creates a CRUD application for the entities, using Grails. The whole process is remarkably Rails-like, as the name might suggest.
    As one impressive example of its enterprise integration abilities, Grails let's you quickly and easily build a web application backed by your existing EJB3 entity beans. But, it doesn't stop there. Grails gives your entity beans a hearty shot of steroids, but does so completely dynamically, without altering your EJB source code in any way. Grails Object Relational Mapping (GORM) is built on Hibernate 3 (but will eventually offer support for the Java Persistence API) and uses Groovy's Meta Object Protocol (MOP) to add all sorts of handy dynamic methods to your otherwise-static entity beans. And those methods are not only accessible from Grails and Groovy; your Java code can invoke those methods as well! We suddenly have all the enterprise-level capabilities of JEE/EJB3 and the benefits of RAD web application development!
    It's a very clear article on the subject matter, although the author seems to confuse Hibernate with JPA in places (suggesting hibernate.cfg.xml instead of the more normative persistence.xml, for example) and, for an "enterprise application," MySQL is used as the database of choice. What do you think of Grails? It's not a standard Java application framework, being based on Groovy instead of Java per se, but has many Rails-like qualities for rapid application development. In addition, the Grails community doesn't seem to have the same arrogance that the Rails community seems afflicted with; is this something that makes it more attractive?

    Threaded Messages (5)

  2. A Few Clarifications[ Go to top ]

    It's a very clear article on the subject matter, although the author seems to confuse Hibernate with JPA in places (suggesting hibernate.cfg.xml instead of the more normative persistence.xml, for example) and, for an "enterprise application," MySQL is used as the database of choice.
    Grails currently uses Hibernate for all persistence work, hence the use of hibernate.cfg.xml. Grails 0.4 is scheduled for release in October and will add support for JPA, at which point you could use a persistence.xml file instead. The article uses MySQL solely due to the fact that it's freely-available for anyone to download, install, and follow along. You could just as easily place vendor X's drivers in the lib directory of your Grails application and change the url and driverClassName accordingly in ApplicationDataSource.groovy. Jason http://jasonrudolph.com
  3. My apologies![ Go to top ]

    My deepest apologies to Jason Rudolph, whose name I, um, changed in the process of posting this. It's not Jason Randolph, it's Jason Rudolph.
  4. What do you think of Grails? It's not a standard Java application framework, being based on Groovy instead of Java per se
    I don't see this as much of a disadvantage; after all, Groovy is being worked on as a JSR.
    In addition, the Grails community doesn't seem to have the same arrogance that the Rails community seems afflicted with; is this something that makes it more attractive?
    Absolutely. I see real potential for Grails, especially when it can use JPA and if the Groovy JSR is finished reasonably soon. It will give very rapid Rails-type development, but based on a more mature ORM approach, and with the option for high performance and easy Java integration. Grails should be far more suitable for legacy/enterprise databases, as illustrated by another of Jason Randolph's articles: http://jasonrudolph.com/blog/2006/06/20/hoisting-grails-to-your-legacy-db/ I very much doubt that Grails will be any significant threat to RoR, but it could mean that developers who want very rapid and agile development for the kind of projects at which RoR is targetted don't have to abandon many advantages of the Java platform, and that is good news.
  5. Comments on Standardization...[ Go to top ]

    I also had some issues with Grails being not standardized at the beginning, but after the Interview with Dierk Koenig, I changed my opinion. Knowing a little about JavaServer Faces, I know what standardization means: long processes, long time to wait! I don't want to hit on JSF, as it also does have its place in the world (even Grails will not be suitable for all projects :-). And after all, Grails is built ontop of J2EE, a mature and *standardized* foundation. So: I think for a "agile" framework like Grails, it is extremely important to be *not* standardized. Being able to react to changes is key here. If you like to listen to Dierk in my podcast, you can checkout the Grails Podcast feed at http://hansamann.podspot.de/rss Cheers\ Sven
  6. Re: Comments on Standardization...[ Go to top ]

    So: I think for a "agile" framework like Grails, it is extremely important to be *not* standardized. Being able to react to changes is key here.
    I don't think it matter if Grails itself isn't standard; I think the use of JSR specs alone will be the thing that will help take-up in many areas. Personally, I was a little disapointed that Grails did not use JSF - having the wide range of JSF components available for use in Grails would be awesome, and combined with facelets (or some groovy equivalent) in the view, it would in my opinion be even more powerful.