Introduction
The Grails framework is getting more momentum every year.
Rapid development frameworks such as Grails allow creating full blown applications very quickly.
By providing high level of abstractions and selecting convention over configuration, relatively complex programs can be written without pain.
Rapid develop frameworks are easy, as long as developers don’t try to fight the framework conventions.
In this blog post, we’ll explore how to use the Grails persistence layer in standalone applications.
In this post, GORM will simply be referred as a ‘persistence layer abstraction’.
Existing resources
Articles and links
In many forums and websites, many users are asking how they can use GORM outside Grails.
Over the years couple of articles have been written, such as the following :
From reading to writing code
After reading the above mentioned articles, getting started is fairly simple:
- Pick a build system with easy dependency resolution/management.
- Setup Spring Beans (XML or Grails Spring DSL or programmatically).
- Setup the datasource as well other relevant beans.
- Setup domain classes.
- Create a simple main class.
- Write additional classes and configuration files.
Why would you want to use Gorm without Grails
While large programs tend to be splitted into modules, it’s not always the case.
Grails domain classes have couple of injected methods to make database queries easily.
As long as you don’t need that many low-level/advanced Hibernate features, using GORM is sweet.
- You may not desire to deal with Hibernate / JPA annotations and/or XML mappings.
- If you already have an existing Grails application, you may need to reuse your persistence layer.
- You want to avoid code verbosity(getters/setters/validators/etc.)
- You may just need a quick database driven admin application and you don’t mind Groovy.
Sometimes its very difficult to reuse some application features in new or existing projects for many reasons:
- Tight coupling.
- Difficult bootstrapping of resources/services/components.
- Inflexible APIs, the program was never written with code reuse in mind.
Most of the Grails applications that I’ve seen/used/written are tightly coupled to the Grails framework itself in all aspects.
- The domain classes may use plugins to specify shared custom constraints among other alternatives.
- Explicit references to some Grails resources that need to be bootstrapped.
- Use of the implicit
logfield that is injected via AST transformations. - Use of other implicit objects that are injected via metaClass magic.
- etc.
Basically trying to split the project into modules could result into unexpected errors:
- Null pointer exceptions.
- Fields missing errors
- Objects initialization errors.
Small example uploaded
You can find a small GORM standalone application on my Github repository.
The application is simple and easy enough to get most people started in no time.
Screencast
Basics
Interceptors and autotimestamp
If you like what you see, please subscribe to our channel and comment!
