Lauro Becker

Java, Grails and other great things

Category Archives: dao

Dao Artefacts Plugin

Introduction

That working with database using Grails is very trivial, everybody knows. You just have to write some domain mappings here, change some connections configurations there, and all works like a charm.

But, well, sometimes we have to do some additional coding around the conventions and we do need write some SQL instructions for a certain kind of database. This kind of thing commonly happens when you’re working with legacy systems. The best approach, with no doubt, would be to map everything as domain classes, and take all Grails’ advantages. But it’s not always possible.

The Problem

In my case, I’m in a project where we had to integrate an old hard coded Struts 1 app with Grails. I’m very lucky of getting everything working really fast with Struts 1 Plugin. Originally the application was developed over PostgreSQL, and now we’re running with Oracle too.  You should be thinking about DAO and DAO Factory patterns. And, I guess, it is the best solution for multiple datasource types.

Probably, before ORM’s era, you should have written tons of SQL instructions in hundreds of DAOs. Then, you always tried your very best for using SQL ANSI. So you’d never need to write specific SQLs. In the most of the situations you achieved it with no problems. But you always had to write some specific code for pagination purposes… Damn!

See how to do it with Oracle and PostgreSQL:

If you’re accustomed with Grails as I am, you may be thinking about how many lines you’ll have to write for achieving this. And, yes, it is a lot of code.

The Solution

I’m coming in this post to present you the new Dao Artefacts Plugin I’ve developed, for making my life easier – hope yours too. In fact, I hope you never need to write any DAO in your shinny Grails apps, but life is not always fair. 😉

Let’s say you have the above situation with Customer’s stuff – and have already installed the plugin. Create a new Groovy class inside grail-app/daos named CustomerDao. Put all your SQL ANSI inside it. Now create a subclass CustomerOracleDao and override all specific methods. Do the same for CustomerPostgresDao.

In your project’s Config.groovy, add the following lines:

grails.plugins.daoartefacts.datasource.name = "Oracle"
grails.plugins.daoartefacts.datasource.all = ["Oracle", "Postgres"]

The first is the actual database name. In this case, we are running over Oracle. The second line has a list of all known databases (for now, Oracle and Postgres).

When the application starts, the plugin looks for all classes inside grails-app/daos with *Dao.groovy pattern, and register them as Spring beans. If no per database class is created, the “ANSI” will be used. So, you don’t have to write factories. The magic happens by the Convention over Configuration paradigm.

Now you only need to inject your new DAO in your services. For example:

class CustomerService {
	def customerDao // Oracle or Postgres DAO, depending on the configuration

	void foo() {
		customerDao.foo()
	}
}

Conclusion

I’ve been seeing people putting native SQLs inside Grails Services. The main goal of this great framework is its productivity, but it doesn’t mean that design patterns should be left behind.

If you were missing a solution for Data Access tier, perhaps this plugin can fit.