Using GORM standalone

Few days ago we decided to get rid of Apache iBatis in one of our projects. We couldn’t longer maintain large XML mapping and query descriptors with mix of Java, SQL and XML itself. But we also wanted to avoid switching to another ORM framework with lot of features and DAO layer requirement. We tried to implement some simple Spring JdbcTemplate-based ORM in Groovy, but it (strangely) started to look just like Hibernate… All that aliases in generated SQL’s, need to use javax.presistence annotations etc. The only simple existing solutions were Groovy’s DataSet (which is not working outside Groovy script) and GORM. Googling ‘GORM standalone’ show just few useful, but rather outdated, results. So I was forced to spend couple of hours to write desired 6 lines of code:

ExpandoMetaClass.enableGlobally()
        SessionFactory sessionFactory = ctx.getBean("sessionFactory")
        def grailsApp = new DefaultGrailsApplication([Customer.class] as Class[], null)
        grailsApp.initialise()
        GrailsHibernateUtil.configureHibernateDomainClasses(sessionFactory, grailsApp)
        HibernatePluginSupport.enhanceSessionFactory(sessionFactory, grailsApp, ctx)

And after annotating Customer class:

@Entity
@Table(name = "CUSTOMERS")
class Customer {
    String firstName
    String lastName
}

Now we are able to enjoy DAO-less code in pure Groovy:

Customer.findAll().each{ println it.firstName }         
        Customer.withCriteria { eq('lastName', 'Smith') }.each { Customer c -> println c.firstName }
        Customer.findByFirstNameAndLastName('John', 'Smith')

PS. For unknown reasons, these 6 lines work only with Grails 1.1.x

You May Also Like

Context menu or Action buttons ?

Recently I was drawn into one of those UI "religious" disputes that has no easy answers and usually both sides are right. One of our web developers was trying out new web tech (with pretty rich widget library) and started to question himself about some basic usability decisions. The low level problem in this case is usually brought to "which widget should I use ?". I'm not fond of bringing the usability problems to questions: Should I use Tabs over Menu ? Or should I use Context menu instead of buttons panel ? But sometimes if time is crucial factor and other usability levels are by default not addressed at all - better developer that asks those basic questions than developer that do not question himself at all.