Grails Packaging Structure for Controller and Domain

[Gregg Bolinger]

In Java I'm used to logically structuring my application into packages. In Grails, most books don't teach this approach but from what I understand, it is still a good idea to package your controllers and domain objects, services, etc.

In Java I'd normally do something like this

com.company.project.domain
com.company.project.services
com.company.project.actions (controllers)

In Grails, the project is already structured out into these areas so how should the packages be structured? Is it redundent to have com.company.project.domain for classes in the grails-app/domain folder ? It's not like the domain folder is actually part of the package so this is where I am confused. Just looking for a little "standards" advice.

[Matthew Taylor]

Gregg, I've got a blog post about this here

[Gregg Bolinger]

Matthew Taylor wrote:Gregg, I've got a blog post about this here

Thanks.

Package names should describe and separate code functionality, not code type.

This is an interesting concept since this isn't what has been preached over the years.

[Matthew Taylor]

Gregg Bolinger wrote:

Matthew Taylor wrote:Package names should describe and separate code functionality, not code type.

This is an interesting concept since this isn't what has been preached over the years.

It is my opinion, and it works specifically well in Grails projects. I've fought this battle in my Java shops in the past, with mixed results.

[Gregg Bolinger]

So the interesting thing here is that you end up with packages that don't really offer anything. How is putting everything under

com.company.project

any different than just not using packages at all?

[Matthew Taylor]

Gregg Bolinger wrote:So the interesting thing here is that you end up with packages that don't really offer anything. How is putting everything under

com.company.project

any different than just not using packages at all?

Because you might have conflicting class names. If you get a reasonably large Grails app, you might have a ChartTagLib that conflicts with the ChartTagLib in a plugin, or something.

[Gregg Bolinger]

Matthew Taylor wrote:

Gregg Bolinger wrote:So the interesting thing here is that you end up with packages that don't really offer anything. How is putting everything under

com.company.project

any different than just not using packages at all?

Because you might have conflicting class names. If you get a reasonably large Grails app, you might have a ChartTagLib that conflicts with the ChartTagLib in a plugin, or something.

Makes sense. Thanks.