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…
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.
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.)
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.
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.
Don’t feel bad, I’ve seen a lot of enterprise java shops do really stupid things with package naming.
12 Comments
Whoops! This is exactly the way I’ve packed up my Grails app. :\
In other words: The same design rules that apply for java packages are valid for Grails packages.
Absolutely.
I did what you suggested and put my domain class into a package. But now in the view (gsp), it cannot find the domain until I include . And the worst part is it doesn’t work on the layout page (main.gsp). Do you have any suggestion ? Thanks.
You’ll just have to import the domain class into your view:
< %@ page import="com.snuff.Foo" %>
This is better than not having packages.
I guess I am a little confused about packages. My assumption was that you can get better MVC separation with packages which can aid in creating different front ends for your domain classes. What is the ideal model/organization in Grails by which you would develop say a desktop web front-end, a mobile web front-end, and a mobile app front-end? Would everything (domains, views, controllers, services) be all part of the same package?
Hi John, that is a really good question, and one that I have not thought about until now. I have an aversion to packaging by code type, as you’ve seen, but in this case I would much rather have an ‘iphone’ package within my app than 2 side-by-side controllers with slightly different names (like FooController & FooIPhoneController). Same thing with the view layers. But I am interested in what the community thinks about this, so I’ve emailed the user group to get some feedback on this relevant question.
I have to admit that I’ve structured my Grails code like that upon till now, although to my defense it has given me a little bad feeling and that’s how I found your blog. I think this is a good way to organize the code. As you say it’s annoying to do lots of imports when grails has different folders for this.
I want to create subdirectories under the standard directories, for examples, controllers/reports to place all my report controllers in there. Is this a good idea? When I try this I can’t seem to give the right URL to find them. E.g. I tried : …. controller:’reports.vehicleAlertSummary’
as in
Vehicle Alert Summary
but with no luck! Any suggestions?
as in
Vehicle Alert Summarybut with no luck! Any suggestions?
Sorry can’t get html/gsp code to show. but hopefully you get my drift.
I don’t think you need to put the package path when specifying your controller in a gsp. You can just refer to reports.VehicleAllerySummaryController as “vehicleAlertSummary”.
(Sorry it took me so long to reply, but you’ll usually get a quick response from someone on the Grails user mailing list)
One Trackback
[...] an interesting post about java packaging here. I hear what he is saying and it makes sense, but I think I’ve always worked in shops that [...]