Grails - how to pass Domain Objects and use services - grails

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.