File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Grails Packaging Structure for Controller and Domain

 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 110
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gregg, I've got a blog post about this here
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 110
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 110
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic