File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Groovy and the fly likes Grails best practices Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Languages » Groovy
Bookmark "Grails best practices" Watch "Grails best practices" New topic
Author

Grails best practices

leandro sabin
Greenhorn

Joined: Aug 06, 2008
Posts: 4
Hi Dave.

I am beginning with Grails, read 2 books about it and am planning to read yours as soon as I can. One of my concerns is the lack of Grails best practices; does your book cover this subject? If not, can you point us to some resources?

Thanks.
Leandro
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3353

Guess it is too early for this question? as it is slowly emerging! -- Hope so!


Everything has got its own deadline including one's EGO!
[CodeBarn] [Java Concepts-easily] [Corey's articles] [SCJP-SUN] [Servlet Examples] [Java Beginners FAQ] [Sun-Java Tutorials] [Java Coding Guidelines]
Dave Klein
author
Ranch Hand

Joined: Aug 29, 2007
Posts: 77
Hi Leandro,

One might argue that the best practices are the ones that work best for you and your projects / users / environment, etc.

That said, the practices that make sense in most other web development environments also apply to Grails, so I don't know of a body of thought on practices specific to Grails.

There are a couple of issues that we could discuss though:

Grails had not done much to encourage the use of packages for domain classes, controllers, etc. Many people giving demos of Grails also didn't use packages since it's quicker and demos are supposed to be short, right? Anyhow, some people took all this together to mean that Grails discouraged the use of packages, which it didn't. So, in the upcoming Grails 1.2, you will get a warning if you try to create a class, using the Grails scripts, if you don't use a package.

Then there's the issue of anemic domain models. http://martinfowler.com/bliki/AnemicDomainModel.html Some think that Grails encourages this practice too. I would say that Grails is pretty neutral about it. But whether the anemic domain model is a pattern or an anti-pattern is a subject that many are still debating. I could tell you my preference but that would have nothing to do with the topic of this forum. If you're interested you can email me at daveklein@usa.net.

I apologize if I appear to be skirting around your question. It's only because I am.

Dave
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Dave, I'd love to hear your opinion on anemic domain models and I think it fits quite well in this forum. Don't ever be concerned about voicing your opinion here. Now, out with it.


GenRocket - Experts at Building Test Data
Dave Klein
author
Ranch Hand

Joined: Aug 29, 2007
Posts: 77
Hi Gregg,

Since you're the sheriff...

I agree with Martin Fowler's view that the anemic domain model is an anti-pattern. I don't feel quite as strongly about it as he does, but I do think that we miss out on much of the value of working with an object oriented language if we allow our domain classes to become just glorified record structures.

I used to think that Grails encouraged this sort of design but I think it's just what we see in demos. I think it might be a side-effect of the DTO pattern. Since we are often forced to move data from domain objects into value objects (basically records) in order to send them across the wire, I think developers begin questioning the value of duplicating everything. So, why not just have our domain classes be DTOs? Then we can put all our logic in a service layer.

This can work and if done carefully isn't a tragedy. Which is why I don't feel as strongly about it as some. However, I think we are more likely to end up with a mess using this style. I've seen many examples (some of them my own) of code that is checking the type of an object before doing something to it inside of a service method. (Here I will get a bit dogmatic) That's evil! If some bit of processing needs to be different based on what object is being acted on, that logic is screaming to become a method of that object or a related one.

My general rule is to put logic as close as possible to the data that it acts on or involves. I don't hold to that rule to the point of paralysis, but I try to do that first. If I can't find a good fit then I will look at moving the logic to a service class or helper class, etc. I am convinced that this principle helps me to end up with better designs.

There's my opinion. I would love to see / hear others.

Dave
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Thanks Dave. That's very good information. This is a common discussion point between me and my colleagues.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Grails best practices