Doi: 10.1145/1498765.1498783
Active Record and GORM use these dynamic capabilities in ways that can significantly simplify an application.
This article looks at how GORM works. It compares and contrasts GORM with Hibernate, focusing on three areas: defining object-relational mapping; performing basic save, load, and delete operations on persistent objects; and executing queries. It describes how GORM leverages the dynamic features of Groovy to provide a different flavor of ORM that has some limitations but for many applications is much easier to use.
A major component of most enterprise applications is the code that transfers objects in and out of a relational database. The easiest solution is often to use an ORM (object-relational mapping) framework, which allows the developer to declaratively define the mapping between the object model and database schema and express database-access operations in terms of objects. This high-level approach significantly reduces the amount of database-access code that needs to be written and boosts developer productivity.
Several ORM frameworks are in use today. For example, the Hibernate, 2 TopLink, 11 and OpenJPA1 frameworks are popular with Java developers, and NHibernate10 is used by many .NET developers. Two newer ORM frameworks that have recently received a lot of attention from enterprise developers are Active Record for Ruby and GORM (Grails Object
15 14
GORM is the persistence component of Grails, which is an open source framework that aims to simplify Web development. Grails is written in Groovy, a dynamic, object-oriented language that runs on the JVM (Java Virtual Machine). Because Groovy interoperates seamlessly with Java, Grails can leverage several mature Java frameworks. In particular, GORM uses Hibernate, a popular and robust ORM framework.
GORM, however, is much more than a simple wrapper around the Hibernate framework. Instead, it provides a very different kind of API. GORM is different in two ways. First, the dynamic features of the Groovy language enable GORM to do things that are impossible in a static language. Second, the pervasive use of CoC (Convention over Configuration) in Grails reduces the amount of configuration required to use GORM. Let’s look at each of these reasons in more detail.
Dynamic Groovy. GORM relies heavily on the dynamic capabilities of the Groovy language. In particular, it makes extensive use of Groovy’s ability to define methods and properties at runtime. In a static language such as Java, a property access or a method invocation is resolved at compile time. In comparison, Groovy does not resolve property accesses and method invocations until runtime. A Groovy application can dynamically define methods and properties.
48 communicAtionS of the Acm | APriL 2009 | voL. 52 | no. 4
References:
Archives