ods are readily available on the domain
classes, GORM avoids the problem of
needing to resolve inter-component
One potential drawback of these
finder methods is that the method
name is the definition of the query. It is
not always possible to define an intentional revealing name for a query that
encapsulates the actual implementation. As a result, evolving business requirements can cause the names of
finder methods to change, which increases the cost of maintaining the application.
For applications that need to execute
more elaborate queries, GORM provides a couple of different options. An
application can execute HQL queries
directly. For example, an application
can execute an HQL query to retrieve
accounts with low balances, as shown
in Figure 5b. This code snippet invokes
the findAll() method, which GORM
injects into each domain class. It takes
an HQL query and a list of parameters
One nice feature of this API is that
it allows an application to execute an
HQL query without explicitly invoking
the Hibernate API. The application
does not have to solve the problem of
obtaining a reference to a DAO or other
component. One drawback, however,
is that knowledge of HQL is hardwired
into the application.
The other option, which is especially useful when constructing queries
dynamically, is to use GORM criteria
queries, which wrap the Hibernate Criteria API described earlier. As with the
other APIs, GORM dynamically injects
a createCriteria() method into
domain classes. This method allows an
application to construct and execute
a query without having an explicit dependency on the Hibernate API.
Figure 5c is the GORM criteria query
version of the query that retrieves accounts with low balances. The createCriteria() method returns an
object for building queries. The application executes the query by calling
list(), which takes a Groovy closure
as an argument and returns a list of
matching objects. The closure argument contains method calls such as
lt() that add restrictions to the query.
Applications can use these APIs
to execute queries that are not sup-
ported by dynamic finders. One potential downside, which could be considered to be a weakness of GORM, is
the potential lack of modularity and
violation of the Separation of Concerns
principle. There is a risk of scattering
the data-access operations for a domain class throughout the application. Some data-access methods are
defined by the domain class, but the
rest are intermingled with the application’s business logic, which could be
considered to be a lack of modularity.
Ideally, such data-access logic should
be encapsulated within DAOs but, unfortunately, GORM does not explicitly
GORM provides an innovative style of
O/R mapping that simplifies application code. One of the key ways it does
this is by leveraging the dynamic features of the Groovy language. GORM
injects persistence-related methods
into domain classes at runtime. It eliminates a significant amount of data-access methods and classes, while still
decoupling the business logic from the
GORM’s extensive use of CoC simplifies application code. Provided that
GORM’s defaults for table and column
names match the schema, a class can
be mapped to the database schema
with little or no configuration. GORM
also injects every domain class with primary-key and version-number fields,
which further reduces the amount of
GORM has some limitations. It does
not easily support multiple databases.
Dynamic finder methods cannot have
an intentional revealing name that
encapsulates the query. GORM lacks
support for DAO classes, even though
complex applications might benefit
from the improved modularity that
they offer. Applications that work with
a legacy schema will not be able to take
advantage of CoC since they require explicit configuration of ORM.
Despite these limitations, developers of a wide range of applications will
find GORM extremely useful. Developers can use GORM independently of
Grails but it is targeted at Web application developers who can benefit from
the rapid development capabilities
of the Grails framework. In addition,
GORM is best used when developing
applications that access a single database or when using database middleware that makes multiple databases
appear as a single database. Developers
will get the most benefit from GORM
when they have control over the database schema and can leverage GORM’s
I would like to thank the following reviewers for the helpful feedback on
drafts of this article: Ajay Govindarajan,
Azad Bolour, Dmitriy Volk, Brad Neighbors, and Scott Davis. I would also like
to thank the members of the SF Bay
Groovy and Grails meet-up and the
anonymous ACM Queue reviewers who
provided feedback on this article.
1. apache openjPa; http://openjpa.apache.org/.
2. bauer, c., and gavin, k.. Java Persistence with
Hibernate. manning Publications, 2006.
3. Dijkstra. e. W. on the role of scientific thought.
in Selected Writings on Computing: A Personal
Perspective. springer-Verlag, 1982, 60–66.
4. Domain-specific language; www.martinfowler.com/
5. fowler, m. inversion of control containers and the
dependency injection pattern; www.martinfowler.com/
articles/ injection.html (2004).
6. java se Desktop technology; http://java.sun.com/
7. koenig, D., glover, a., king, P., laforge, g., and skeet, j.
Groovy in Action. manning Publications, 2007.
8. marinescu, f. EJB Design Patterns: Advanced Patterns,
Processes, and Idioms. manning Publications, 2007.
9. mellqvist, P. Don’t repeat the Dao! 2006; www.ibm.
10. nhibernate; http://sourceforge.net/projects/
11. oracle toplink; www.oracle.com/technology/
12. rocher, g. The Definitive Guide to Grails. apress, 2006.
13. the spring framework reference Documentation. see
14. thomas, D., fowler, c., and hunt, a. Programming
Ruby: The Pragmatic Programmers’ Guide. Pragmatic
15. thomas, D., hansson, D., breedt, l., clark, m., fuchs,
t., and schwarz, a. Agile Web Development with Rails.
Pragmatic bookshelf, 2005.
16. Walls, c., breidenbach, r. Spring in Action, second
edition. manning Publications, 2007.
Chris Richardson is a developer and architect with more
than 20 years of experience. he is the author of POJOs
in Action (manning Publications, 2006), which describes
how to build enterprise java applications with Pojos and
lightweight frameworks. he runs a consulting and training
company that specializes in helping companies reduce
development costs and increase developer effectiveness.
he has been a technical leader at insignia, bea, and
elsewhere. richardson is the founder of cloud tools, which
is a source project for deploying java applications on
amazon ec2, and of cloud foundry, a startup that provides
outsourced datacenter management for java applications
on the cloud. he has a computer science degree from the
university of cambridge in england and lives in oakland,
a previous version of this article appeared in ACM Queue,
© 2009 acm 0001-0782/09/0400 $5.00
APriL 2009 | voL. 53 | no. 4 | communicAtionS of the Acm