• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Grails best practices

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 3389
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guess it is too early for this question? as it is slowly emerging! -- Hope so!
 
author
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
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
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.
 
Dave Klein
author
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
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
Thanks Dave. That's very good information. This is a common discussion point between me and my colleagues.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic