Recently, my friend and colleague asked some questions about package naming conventions in Grails. I think they were excellent questions, and I wouldn’t be surprised if others were wondering about the same things. You could get into arguments with some guys over stuff like this, but here is my opinion…
com.businessname.appname
Is there an inherent advantage to that package naming convention? Do you use this package naming by default, or is it does it vary according to certain designs?
This is pretty standard, and a lot of J2EE shops do it this way. There is nothing forcing you, however, but I think this is the right way.
Let’s say your company is WidgetCo Inc, and they have a website at www.widgetco.com. They want a new webapp called “Spanky” that will allow online ordering.
com.widgetco.spanky
This package structure will allow them to create a new webap in the future for their internal payroll (or whatever):
com.widgetco.payroll
So com.widgetco is their company package, and where they can park all their applications.
I saw a post on the Grails mailing list about someone having a package names like:
com.businessname.appname.domain and com.businessname.appname.controller, etc.
Does adding the “domain” or “controller” have an advantage? Seems like it would obviously prevent name clashes, but it also seems like overkill.
Don’t do this! This is bad. Grails creates these separations for you within grails-app by having controller and domain folders. The point being that you can have your Foo domain object, FooController, FooService, FooJob, FooEtc, and FooTests all in the same convenient package. When people start putting ‘domain’, ‘controller’, ’service’, etc. in their package names, they ruin that. Now there will be lots of importing. Boo!
We have a client that still has all their domain objects in a ‘domain’ package, and every time I go work with them I complain to them about it because I have to see so many meaningless import statements! So I’m in the FooController, and I need to import the Foo class? That sucks, IMHO. (They still haven’t done it because, as you know, repackaging is a huge pain in the ass! So get your packaging right early.)
Package names should describe and separate code functionality, not code type.
The aforementioned ‘domain’ package is describing what type of code is within: the domain classes. I don’t think this is a good idea, since Grails has already provided this type of code separation at a higher level.
The right reason to create a new package is because you have some specific code functionality that might spread over your application. For example, say you have written a very specific rule engine in your app. You might keep it in /src/groovy/com/company/app/rules/RulesEngine.groovy. This may have a Rule domain object associated with it, and it would go in /grails-app/domain/com/company/app/rules/Rule.groovy. Also, maybe a rule service in /grails-app/services/com/company/app/rules/RuleService.groovy, etc.
I assume that it’s in the best interest of devs to decide on a package naming convention earlier rather than later.
Absolutely. I think the best time to start packaging a Grails app is after you’ve run grails create-domain-class foo. Once you have a paradigm set for your application, making new classes conform to it is not a big deal. I can be royally painful to apply a packaging model as an afterthought.
I haven’t seen many Grails tutorials/intros that deal with this issue. I’m also a n00b when it comes to package naming in Java/Grails projects, so this could be one giant “DUH ” or RTFM” question.
Don’t feel bad, I’ve seen a lot of enterprise java shops do really stupid things with package naming.
