Having tackled the conventional approach to Grails domain models as well as an XML-based solution for hooking Grails up to a non-conforming schema, it’s time to consider another option.

Whether you’re disheartened by writing too much XML (and prefer annotations instead), or you’re looking for a domain model solution you can use both with Grails and without Grails, EJB3 entity beans will get your where you want to be. In “Advanced Domain Models in Grails”, we’ll see the exact steps needed to take your plain ol’ statically-typed EJBs, and equip them with the dynamic superpowers of Grails domain classes (all without adding a single line of code to those poor POJOs). Feel free to download the sample app and take it for a spin. (Be sure to have a look at the included README files for all the details.)

Don’t have any EJB3 entity beans to use with Grails yet? No problem. The Ant script included in the download (and first discussed in yesterday’s post) not only includes the ability to reverse engineer Hibernate mapping files from a database schema, but also to produce EJB3 entity beans based on the schema. Once again, you’ll likely want to tweak the output somewhat to get your classes looking just the way you want them, but compared to manually performing the DB-to-POJO mapping, this tool is incredibly handy. (Thanks again to Raffaele Castagno for providing this script.)

Knowing that Grails embraces convention over configuration, is there any room left for a fourth part to this series? (Hint: “Convention over configuration” != “Convention instead of configuration.”)

We began Part 1 of this adventure with a greenfield application that chose to kindly comply with all the standard Grails conventions. Now it’s time to venture into the land of non-conformity.

We first looked at hooking Grails up to a non-standard schema over a year ago now, way back in the days of Grails 0.1. This clearly remains a topic of much interest, as that tutorial has held its ground week in and week out for 13 straight months as the most highly-trafficked post on this site. Grails has seen significant progress since then, so an updated example is certainly in order.

In “Advanced Domain Models in Grails”, I’ll demo the exact steps needed to gain all the dynamic persistence goodness that GORM has to offer, regardless of whether your schema plays nicely with the Grails conventions. With just a sprinkling of configuration - 5 minutes of effort or less - we’ll be up and running. In fact, you can download and try out the app now. (Be sure to have a look at the included README files for all the details.)

To make this process even easier, the download includes an Ant script developed by Raffaele Castagno for reverse engineering the schema to produce the initial Hibernate mapping files for you. The resulting HBM files will need a bit of tweaking (as you would expect, since the whole point of this exercise is that your schema doesn’t map cleanly to your domain classes), but compared to coding up the HBM files from scratch, this tool is incredibly handy.

Keep an eye out for Part 3, where we invite EJB3 entity beans to the party. Stay tuned.

For any developer that’s ever touched JDBC (and it’s safe to assume that’s most Java devs, right?), GORM is one of the many Grails features that addresses a clear and prominent pain point in the Java space. Put simply, GORM is humane ORM. It means leaving the low-level database-related plumbing to the framework and instead investing your time in the business tier. After all, your app needs to solve a business problem, right? And it’s a pretty safe bet that your business analysts didn’t spend time listing out any requirements about managing DB connections, result sets, sessions, or DAO code. Nope. They’re focused on a much higher level, and we should be too.

If you’re fortunate enough to be developing a greenfield application, you can just follow the Grails conventions and come close to forgetting that there’s a database under the covers at all. GORM dynamically equips you with all the persistence methods you need to manage your domain, and yet you still have the ability to drop down to that lower level should the need arise.

NFJS is in RTP this weekend, and in “Advanced Domain Models in Grails”, I’ll be looking first at the functionality that GORM provides out-of-the-box and then exploring how you can mold GORM to take advantage of its benefits in a variety of environments. We’ll start by looking at a sample app that colors within the lines of the Grails conventions, and you can download and try out that app now. (Be sure to have a look at the included README files for all the details.)

Inside the app you’ll find working examples of various relationship types (including many-to-many, which people occasionally struggle with at first), constraints, and the always-cool dynamic finders. Check out the test cases in test/integration. Among other things, the test cases illustrate exactly how the entities relate to one another. (Want to know which side of a many-to-many relationship can perform a cascading save operation? Check out the tests.) To run the tests, just execute grails test-app from the command line.

Of course, there’s just no substitute for hands-on experimentation. To interact with the domain models yourself, simply navigate into the project directory and run grails console to get an interactive shell where you can experiment with the domain objects first-hand. Or better yet, write additional tests of your own! If you get adventurous (and I hope you do), try out some of the many other possibilities available in GORM.

Be sure to watch for Part 2, where we begin our venture into the land of non-conformity. Stay tuned.

In one fell swoop, the Groovy team and JetBrains have seemingly annihilated the biggest reason (and perhaps the only reason) not to use Groovy in your Java project. With today’s release of Groovy 1.1-beta-2, you can now use the groovyc compiler to jointly compile both your Groovy and Java classes. And here’s the kicker: it manages all the dependencies for you! Groovy class A extends Java class B which references Groovy class C? No problem.

Read the rest of this entry »