Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What logic should go in the domain class and what should go in a service in Grails?

Tags:

oop

grails

I am working on my first Grails application, which involves porting over an old struts web appliction. There is a lot of existing functionality, and as I move things over I'm having a really hard time deciding what should go in a service and what should be included directly on the model?

Coming from a background of mostly Ruby on Rails development I feel strongly inclined to put almost everything in the domain class that it's related to. But, with an application as large as the one I'm porting, some classes will end up being thousands upon thousands of lines long.

How do you decide what should go in the domain versus what should go in a service? Are there any established best practices? I've done some looking around, but most people just seem to acknowledge the issue.

like image 329
Zachary Wright Avatar asked Apr 04 '12 16:04

Zachary Wright


People also ask

What is Grails domain class?

A domain class fulfills the M in the Model View Controller (MVC) pattern and represents a persistent entity that is mapped onto an underlying database table. In Grails a domain is a class that lives in the grails-app/domain directory.

What are Grails services?

Services in Grails are the place to put the majority of the logic in your application, leaving controllers responsible for handling request flow with redirects and so on.

How do you build a Grails project?

Go to start.grails.org and use the Grails Application Forge to generate your Grails project. You can choose your project type (Application or Plugin), pick a version of Grails, and choose a Profile - then click "Generate Project" to download a ZIP file. No Grails installation necessary!


1 Answers

In general, the main guideline I follow is:

If a chunk of logic relates to more than one domain class, put it in a service, otherwise it goes in the domain class.

Without more details about what sort of logic you are dealing with, it's hard to go much deeper than that, but here's a few more general thoughts:

  1. For things that relate to view presentation, those go in tag libs (or perhaps services)
  2. For things that deal with figuring out what to send to a view and what view to send it to, that goes in the controllers (or perhaps services)
  3. For things that talk to external entities (ie. the file system, queues, etc.), those go in services

In general, I tend to err on the side of having too many services than having things too lumped together. In the end, it's all about what makes the most sense to you and how you think about the code and how you want to maintain it.

The one thing I would look out for, however, is that there's probably a high level of code duplication in what you are porting over. With Grails being built on Groovy and having access to more powerful programming methods like Closures, it's likely that you can clean up and simplify much of your code.

like image 93
cdeszaq Avatar answered Oct 29 '22 14:10

cdeszaq