ods are readily available on the domain classes, GORM avoids the problem of needing to resolve inter-component references.

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 as arguments.

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 support them.

Summary

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 ORM framework.

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 coding required.

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 CoC features.

Acknowledgments

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.

 

References

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/ bliki/ Domainspecificlanguage.html.

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/ javase/technologies/desktop/javabeans/index.jsp.

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. com/developerworks/java/library/ j-genericdao.html.

10. nhibernate; http://sourceforge.net/projects/ nhibernate/.

11. oracle toplink; www.oracle.com/technology/ products/ias/toplink/ index.html.

12. rocher, g. The Definitive Guide to Grails. apress, 2006.

13. the spring framework reference Documentation. see @configurable; http://static.springframework.org/ spring/docs/2.5.x/reference/ index.html.

14. thomas, D., fowler, c., and hunt, a. Programming Ruby: The Pragmatic Programmers’ Guide. Pragmatic bookshelf, 2004.

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, ca; www.chrisrichardson.net.

a previous version of this article appeared in ACM Queue, may/june 2008.

© 2009 acm 0001-0782/09/0400 $5.00

APriL 2009 | voL. 53 | no. 4 | communicAtionS of the Acm

55