views:

340

answers:

3

I need to inject a service based on domain property, so far I came up with the following:

ApplicationHolder.application.getServiceClass("package.${property}Service").clazz

but loading it this way doesn't inject it's dependent services. Am I doing it wrong?

A: 

Yes. Services aren't injected into domain objects. If your domain object needs something for a particular use case, let the service that owns that use case invoke the other service on the domain object's behalf.

duffymo
Any Spring bean can be injected into domain classes just like in controllers, i.e. "def fooService". The common use case for this is to call a service in a custom validator.
Burt Beckwith
Can be; I just disagree that it should be. A validator is different from a domain object like an Account or a Person. It's a completely different use case.
duffymo
+6  A: 

New instances will bypass Spring's dependency management; you need to get the configured singleton bean from the application context. Use this instead:

def service = ApplicationHolder.application.getMainContext.getBean("${property}Service")

That assumes that 'property' is the partial bean name for a service, i.e. for FooBarService, the property would have to be 'fooBar'. If it's 'FooBar' then you can use GrailsNameUtils.getPropertyName() to fix it:

import grails.util.GrailsNameUtils

String beanName = GrailsNameUtils.getPropertyName(property) + 'Service'
def service = ApplicationHolder.application.getMainContext.getBean(beanName)
Burt Beckwith
Yay, it works. I tried getBean method, but was passing 'FooBar' to it :)
rukoche
+2  A: 

IMHO domain classes shouldn't contain logic at all (apart form the validators).

In my projects I normally create a service for each domain class (e.g. UserService for class User) and I stick all the logic in there, even small bits in pieces that would normally be in the domain class.

I think a lot of programmers coming from Java/C++ world tend to find this ugly, but it suits better the Grails architecture.

Mulone
It's true that Grails domain classes aren't really suited for logic, but this is a shame because I have to agree with Fowler on this one: http://en.wikipedia.org/wiki/Anemic_Domain_Model
Kimble