wood burning stoves 2.0*
The moose likes Groovy and the fly likes Grails Packaging Structure for Controller and Domain Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Languages » Groovy
Bookmark "Grails Packaging Structure for Controller and Domain" Watch "Grails Packaging Structure for Controller and Domain" New topic
Author

Grails Packaging Structure for Controller and Domain

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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.


GenRocket - Experts at Building Test Data
Matthew Taylor
Rancher

Joined: Jun 13, 2004
Posts: 110
Gregg, I've got a blog post about this here


Grails Consultant
http://dangertree.net
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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
Rancher

Joined: Jun 13, 2004
Posts: 110
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
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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
Rancher

Joined: Jun 13, 2004
Posts: 110
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
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Grails Packaging Structure for Controller and Domain