2010-05-11 8 views
5

necesito para inyectar un servicio basado en la propiedad de dominio, hasta el momento se me ocurrió lo siguiente:Grails: dinámicamente inyectan servicio en la clase de dominio

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

pero la carga de esta manera no inyecta Es servicios dependientes . ¿Lo estoy haciendo mal?

Respuesta

15

Las nuevas instancias omitirán la administración de dependencias de Spring; necesita obtener el bean singleton configurado desde el contexto de la aplicación. Use este lugar:

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

Eso supone que la 'propiedad' es el nombre del bean parcial para un servicio, es decir, para FooBarService, la propiedad tendría que ser 'parametro'. Si se trata de 'parametro', puede utilizar GrailsNameUtils.getPropertyName() para solucionarlo: clases de dominio

import grails.util.GrailsNameUtils 

String beanName = GrailsNameUtils.getPropertyName(property) + 'Service' 
def service = ApplicationHolder.application.getMainContext().getBean(beanName) 
+0

Sí, funciona. Probé el método getBean, pero estaba pasando 'FooBar' :) – rukoche

+0

Lo anterior no funcionaba para mí hasta que reemplacé '.getMainContext' con' .getMainContext(). ' – sebnukem

+0

Gracias, lo arreglé después de ver que su la edición se rechazó incorrectamente –

0

Sí. Los servicios no se inyectan en objetos de dominio. Si su objeto de dominio necesita algo para un caso de uso particular, permita que el servicio que posee ese caso de uso invoque el otro servicio en nombre del objeto del dominio.

+2

Cualquier Spring bean se puede inyectar en las clases de dominio al igual que en los controladores, es decir, "def fooService". El caso de uso común para esto es llamar a un servicio en un validador personalizado. –

+0

Puede ser; Simplemente no estoy de acuerdo con que así sea. Un validador es diferente de un objeto de dominio como una Cuenta o una Persona. Es un caso de uso completamente diferente. – duffymo

3

en mi humilde opinión no deben contener la lógica del todo (aparte formar los validadores).

En mis proyectos normalmente crear un servicio para cada clase de dominio (por ejemplo UserService para la clase usuario) y me quedo toda la lógica de allí, incluso pequeños trozos en piezas que normalmente estarían en la clase de dominio.

Creo que muchos programadores procedentes del mundo Java/C++ tienden a encontrar esto feo, pero se adapta mejor a la arquitectura de Grails.

+3

Es cierto que las clases de dominio Grails no son realmente adecuadas para la lógica, pero es una pena porque tengo que estar de acuerdo con Fowler en este: http://en.wikipedia.org/wiki/Anom_Domain_Model – Kimble

+1

Indeed , Eric Evans probablemente sintió una perturbación en la fuerza, cuando alguien dice "las clases de dominio no deberían contener ninguna lógica". Eso suena como un anti patrón de objetos de Dominio y es completamente contrario al Diseño impulsado por Dominio. –

+0

En mi caso, me gustaría establecer un índice TTL basado en el entorno de Grails. ¿Cuál es un mejor patrón para esto? – Kirby

Cuestiones relacionadas