• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Grails Packaging Structure for Controller and Domain

 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Rancher
Posts: 110
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gregg, I've got a blog post about this here
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic