Monday, June 05, 2006

Grails & EJB3 Entity beans

One of the features that I mentioned at JavaOne that got people all excited was Grails' support for EJB3 entity beans. Grails comes with it's own ORM solution built on-top of Hibernate called GORM, but because of this relationship with Hibernate Grails domain models can also be written in Java.

One way to do this is to use the EJB3 annotation support in Hibernate which will of course allow you to use all the power the API offers in terms of mapping onto legacy systems. Clearly this is all not that exciting so far, what is really exciting is that even though the EJB3 entities you've created are written in Java and mapped using Java persistence annotations you can still use all those fantastic dynamic finder/persitence methods to manipulate your domain model from a Grails controller or service class!

Some examples of these in action are listed below, Grails uses the properties of the domain class itself (combined with the wonderful Criteria API) to implement the finders:

def a = new Author(name:'Stephen King').save()
def b = new Book(author:a, title:'The Stand').save()

def results = Book.findAllByTitle("The Stand")

results = Book.findAllByTitleLike("Harry Pot%")
results = Book.findAllByReleaseDateBetween( firstDate, secondDate )
results = Book.findAllByReleaseDateGreaterThan( someDate )
results = Book.findAllByTitleLikeOrReleaseDateLessThan( "%Something%", someDate )

// find by relationship
results = Book.findAllByAuthor( Author.findByName('Stephen King') )

This is one of the awesome features of Groovy's Meta Object Protocol (MOP), it allows you to add new methods, properties,constructors etc. to any existing Java class, it doesn't have to extend GroovyObject or have any knowledge of the Groovy runtime environment. Think of it as AOP without the byte code manipulation.

Taking this approach is quite appealling at it allows the blended development I mentioned in the talk. Mixing dynamic and static typing is the way to go in my opinion. The debate between these two is a bit of a red herring. This way you have all the power of static typing with its refactoring capability in IDEs, plus the ability to use a dyanmic framework like Grails as the view/controller layer in your web application.

You can also then re-use your domain model across tiers or from regular servlets or via a Swing interface very simply because it is still in Java. The main target for Grails has always been to create a framework with the essence of Rails, but taking Java integration to a new level. Features like this are exactly what is helping us achieve this very goal.


Tom said...

But if you refactor the static side, the dynamic side breaks. And "show references" won't tell the truth, either.

For a dynamic language to be appealing from this front, we need freely available tools that "just work" providing the same features as for static languages. Otherwise, the static-typing benefits still die off.

That may be a worthwhile trade off for some needs, but half static doesn't really work the same as all static.

Graeme Rocher said...

depends on your IDE, IntelliJ allows you to include text files that match to the refactoring. And in Groovy you can alias an imported class name like this:

import com.mycompany.MyClass as MC


Thus renaming the class would be picked up by the IDE.

Clearly though you make a good point as not all refactorings would work. However this is where Groovy as a language is an interesting proposition as it allows both static and dynamic typing hence refactoring tools could be made to work. All it involves is further development on the IDE support.

In addition to this web actions in Grails are very concise, and if you logic becomes complex we encourage use of a Service class (business layer). This of course all depends on the requirement, the point remains is that Grails can scale in terms of application complexity.

John McClean said...

I think the one of the big benefits of Groovy is the fact that the integration with Java is seamless. This means you can leverage the dynamism of Groovy/Grails where it makes sense to do so while retaining the ability to develop large parts of your code base in tooled, statically typed pre-compiled Java.

For risk averse developers the best solution may be to use Groovy/Grails for the CRUD stuff but leave the rest of their app in plain old Java.

derfefww said...

I am so happy to get some hero gold and the hero online gold is given by my close friend who tells me that the hero online money is the basis to enter into the game. Therefore, I should buy hero gold with the spare money and I gain some hero money from other players.

Anonymous said...

One day my friend told me that had a game is very interesting and adapt to me play and gave me some lineage 2 adena, hope me to play, with the l2 adena, in the game slowly I had more cheap lineage 2 adena, this is good, but I still buy lineage 2 adena from the website.

cheap wow power leveling said...

Buy Warcraft(wow power leveling)please point machine (wow power leveling)to enter the website(wow power leveling)of Warcraft

cheap wow power leveling said...

Buy Warcraft(wow power leveling)please point machine (wow power leveling)to enter the website(wow power leveling)of Warcraft

Anonymous said...

^^ nice blog!! ^@^

徵信, 徵信網, 徵信社, 徵信社, 感情挽回, 婚姻挽回, 挽回婚姻, 挽回感情, 徵信, 徵信社, 徵信, 徵信, 捉姦, 徵信公司, 通姦, 通姦罪, 抓姦, 抓猴, 捉猴, 捉姦, 監聽, 調查跟蹤, 反跟蹤, 外遇問題, 徵信, 捉姦, 女人徵信, 女子徵信, 外遇問題, 女子徵信, 外遇, 徵信公司, 徵信網, 外遇蒐證, 抓姦, 抓猴, 捉猴, 調查跟蹤, 反跟蹤, 感情挽回, 挽回感情, 婚姻挽回, 挽回婚姻, 外遇沖開, 抓姦, 女子徵信, 外遇蒐證, 外遇, 通姦, 通姦罪, 贍養費, 徵信, 徵信社, 抓姦, 徵信, 徵信公司, 徵信社, 徵信公司, 徵信社, 徵信公司, 女人徵信,

徵信, 徵信網, 徵信社, 徵信網, 外遇, 徵信, 徵信社, 抓姦, 徵信, 女人徵信, 徵信社, 女人徵信社, 外遇, 抓姦, 徵信公司, 徵信社, 徵信社, 徵信社, 徵信社, 徵信社, 女人徵信社, 徵信社, 徵信, 徵信社, 徵信, 女子徵信社, 女子徵信社, 女子徵信社, 女子徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信社,

徵信, 徵信社,徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 外遇, 抓姦, 離婚, 外遇,離婚,

徵信社,徵信, 徵信社, 徵信, 徵信社, 徵信,徵信社, 徵信社, 徵信, 外遇, 抓姦, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信社, 徵信社, 徵信社,徵信,徵信, 徵信, 外遇, 抓姦