Lauro Becker

Java, Grails and other great things

Dao Artefacts Plugin


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: = "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() {


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.


3 responses to “Dao Artefacts Plugin

  1. Lucas Teixeira January 16, 2012 at 8:19 pm

    Great post mate!

    You should check “Multiple Datasources” feature, included in Grails 2.0.
    It could help in some cases, defining multiple datasources for your domain classes and “prefixing” queries like: and Person.postgres.findAll()

    • laurobecker January 16, 2012 at 8:52 pm

      Hey Lucas!

      Actually plain SQLs are just the the tip of the iceberg. Some times I have to call stored procedures… And read (if wasn’t enough) Oracle’s Struct type (oracle.sql.STRUCT), for example.

      I guess, in these situations, you have to apply DAO Factory pattern – otherwise you’ll be doomed to tie your application to one database type.

      Many thanks for you comment!

      • Lucas Teixeira January 16, 2012 at 8:56 pm

        Thats true. If you have some tricks in your data access layer, such procs, and other black magic steps, this approach is better to abstract all these from your application! 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: