Question

I’m writing a service that shouldn’t have to save anything. It gets some values. Looks up a few things in the database, and then coughs back a response. Is there anything I should do to make the service faster/less overhead? Also whats the best way to pass it something. I usually pass the id and get it again; is that good/bad/dumb?

example

class DoStuffController {
  def ExampleProcessingService
  def yesDoIt = {
    def lookup = "findme"
    def theObject = ExampleThing.findByLookie(lookup)
    def lolMap = ExampleProcessingService.doYourThing(theObject.id)
    if(lolMap["successBool"]){
      theObject.imaString = "Stuff"
      theObject.save()
    }
    []
  }
}

service

class ExampleProcessingService{
  static transactional = true //???????? false? not-a?
  def doYourThing = {theID ->
    def returnMap = [:]
    def myInstance = ExampleThing.get(theID)
    if(myInstance.something)returnMap.put "successBool", true
    else returnMap.put "successBool", false
    return returnMap
  }
}

domain object

class ExampleThing {

  String imaString
  String lookie
  static constraints = {
    imaString(nullable:true)

  }
  def getSomething() {
    return true
  }
}

bootstrap

import learngrails.*
class BootStrap {

    def init = { servletContext ->
        def newThing = new ExampleThing(lookie:"findme")
        newThing.save()
    }
    def destroy = {
    } 
}

Is the an advantage, disadvantage or standard to passing ID and doing get vs. passing the object? Does this change given my case of not going to save anything in the service? Is there something I’m doing glaringly wrong? Do you have a better suggestion for the title?

Answer 1

You’ve asked a lot of questions, and should split this into several individual questions. But I’ll address the overall issue – this approach is fine in general.

There’s not a lot of overhead in starting and committing a transaction that doesn’t do any database persistence, but it is wasteful, so you should add

static transactional = false

In this case you’re using the class as an easily injected singleton helper class. It’s convenient to do transactional work in services because they’re automatically transactional, but it’s far from a requirement.

One thing though – do not use closures in services. They’re required in controllers and taglibs (until 2.0 anyway) but should always be avoided in services and other classes. If you’re not using the fact that it’s a closure – i.e. passing it as an object to a method as a parameter, or setting its delegate, etc. – then you’re just being way too groovy. If you’re calling it like a method, make it a method. The real downside to closures in services is that when you want them to be transactional, they cannot be. This is because Spring interceptors intercept method calls, not closure calls that Groovy pretends are method calls. So there won’t be any interception for transactions, security, etc.