Beyond the quickstart

Is Grails suitable for the Java enterprise? You bet!


VMware’s Groovy and Grails advocate Peter Ledbrook goes beyond your bog standard quickstart to Grails to truly explore how it can be used in an enterprise environment.

Most introductions to Grails focus on quickly building a new web application on top of a fresh database schema. Both the modelling of the domain (the classes that map to database tables) and the scaffolded HTML user interface make it trivially easy to get started. But what does it offer beyond that quickstart? Is it a serious option within the Java enterprise? The answer to this is emphatically “yes” and I’ll take you through some of the features of the framework that make it suitable for such an environment.

Why scaffolding?

When you create a domain model, you want to be able to interact with it via a user interface, adding, changing and deleting data. This is what scaffolding provides. Given a domain class such as:

class Book {
    String title
    String author

    static constraints = {
        title blank: false
        author blank: false

you can generate a CRUD web user interface simply by adding a matching controller class that has the scaffold static property:

class BookController {
    static scaffold = Book

When the application is running, you can create, view, modify and delete instances of Book via a standard set of URLs.

Few real web applications are based on scaffolding, so what value does it really provide? Is it just a gimmick? Not at all. Don’t underestimate the value of getting a working application up and running quickly and efficiently. Even beyond that, scaffolding has great value in several scenarios.

Supporting development of the real UI

While you are building what will be the final user interface for your web application, there will be many occasions when you want to interact fully with the data, particularly to test some feature you are working on. If you have the scaffolded UI enabled, you can interact with the data to your heart’s content from within your browser. This is much more productive for a typical developer than dealing with a database client tool and SQL scripts.

It’s very easy to disable the scaffolding once the initial application is ready, so it’s not like you will end up polluting your lovely user interface with scaffolded pages. Alternatively, consider this second scenario.

Adminstration UI

How many times have you wanted to fix some data after an application or website has gone live? Typically the web application won’t allow you to do this, so you may have to release a new version or (horror!) modify the data directly in the database. Wouldn’t it be better to have a secured administrator UI that gives you full access to the domain model?

You can readily secure scaffolded controllers with something like the Spring Security plug-in, so why not keep them and just make sure only administrators can access the pages? It’s ideal as a fallback option if you can’t do what you need to via the main UI.

Very large domain models

What if you have 50 or a hundred or even more domain classes? Creating a web application for all of these takes a lot of work. Scaffolding can help here and could form the basis of your entire application. You’re not limited to the standard look and feel: scaffolding uses templates that you can readily customise. Simply change the CSS or replace the entire HTML, perhaps even use a JavaScript library of your choice. It’s up to you.

Speaking of large domain models, creating those in the first place can be time consuming if you do it by hand. Fortunately, you have some options here.

Existing databases

The default implementation of GORM (Grails Object-Relational Mapping) is based on Hibernate and this allows for some interesting techniques. For example, many Java enterprises have existing domain models based on Hibernate or JPA. Why would they accept any requirement to recreate that model using an alternative syntax? It sounds like unnecessary effort.

Fortunately, Grails can use an existing model as long as it has either XML Hibernate mappings or uses JPA annotations. The details of how to do this are available elsewhere, but basically you include the model in the Grails project either as Java source or as a JAR; create a Hibernate configuration file; and add GORM constraints in separate files. You then have full access to all the nice features Grails provides, such as dynamic finders, Where queries, the ‚errors’ property, etc.

What if you don’t have an existing model or you really would like to have a full-blown standard GORM model? For this case we have the Reverse Engineer plug-in, which will generate a GORM model from an existing database schema. It’s not a silver bullet – the model will undoubtedly require tweaking – but it can save you a lot of time if you have many database tables. It’s much easier to customise existing files than create them all from scratch.

Such domain models may be created for a single web application, but in the enterprise it’s just as likely that the same database and schema will be used by multiple applications. It would be great if you could package the model with its constraints and perhaps add some coarse-grained services to make it more convenient to work with.

Leveraging plug-ins

The standard unit of packaging in Java is the JAR. These can of course be used by Grails too, but a simple collection of classes misses out on the rich conventions and artifact types provided by Grails. For example, how would Grails know that a particular class is a tag library or a controller?

That’s where plug-ins come in. At the most basic level, they package up functionality by artifact type so that you can share that functionality between multiple applications. Once a plug-in is installed in an application, all its domain classes, services, tag libraries, etc. are available as if the application had defined them itself.

Imagine dropping a plug-in into your application and being able to immediately use well-defined services to interact with an existing database. The plug-in might even contain standard UI elements for viewing parts of the domain model – just use them from your own views. The plug-in mechanism isn’t just for providing things like Spring Security integration or MongoDB support. It’s there to also help you decompose your applications into flexible, reusable pieces. And one of the great things about plug-ins is that they are just like Grails applications, so you don’t even have to learn anything new to make use of them.

Wrapping up

One of the key principles behind Grails is to make it easy for a Java developer to create web applications, while providing the flexibility to integrate with existing systems. GORM embodies that principle in the way that you can integrate with existing domain models without sacrificing the convenience of dynamic finders, Where queries and scaffolding.

I have only scratched the surface here. For example, you can use the same GORM API for NoSQL stores, making them instantly accessible. And yet you can always drop down to their native interfaces when you need to access to their special features. Outside of GORM, Grails is built on Spring and allows you the full power of that framework if you need it.

Grails is a great way to build web applications in the Java enterprise, and you can get started by using it for rapid prototyping. The tools and integration points you need are there, and you can then have some fun exploring the plug-in ecosystem to get things like simple access control, job scheduling, and more!

Author Bio: A long-time Grails user, Peter is currently a committer to the project and officially Grails Advocate at SpringSource, a division of VMware. He is also co-author of Grails in Action with Glen Smith.

This article originally appeared in Java Tech Journal – The Groovy Universe. Find more Groovy-related articles here.

A long-time Grails user, Peter is currently a committer to the project and officially Grails Advocate at SpringSource, a division of VMware. He is also co-author of Grails in Action with Glen Smith.

Inline Feedbacks
View all comments