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

Spring Security by example: securing methods

This is a part of a simple Spring Security tutorial:

1. Set up and form authentication
2. User in the backend (getting logged user, authentication, testing)
3. Securing web resources
4. Securing methods
5. OpenID (login via gmail)
6. OAuth2 (login via Facebook)
7. Writing on Facebook wall with Spring Social

Securing web resources is all nice and cool, but in a well designed application it's more natural to secure methods (for example on backend facade or even domain objects). While we may get away with role-based authorization in many intranet business applications, nobody will ever handle assigning roles to users in a public, free to use Internet service. We need authorization based on rules described in our domain.

For example: there is a service AlterStory, that allows cooperative writing of stories, where one user is a director (like a movie director), deciding which chapter proposed by other authors should make it to the final story.

The method for accepting chapters, looks like this:

Read more »