documentacion docs grails groovy service grails-controller

docs - grails documentation 2.4 4



Grails: clases de servicios VS Groovy (3)

En realidad, los servicios no son solo transacciones. Los servicios son excelentes para componentes singleton inyectables de configuración cero, y se pueden volver a cargar sin reiniciar todo el entorno de Grails Y se pueden descubrir como artefactos y, por lo tanto, se pueden exponer automáticamente con complementos remotos.

La documentación dice:

El equipo de Grails desalienta la incorporación de la lógica de la aplicación central dentro de los controladores, ya que no promueve la reutilización y una separación clara de las preocupaciones.

Tengo un controlador de API y algunas clases Groovy en la carpeta src / groovy. Esas clases simplemente implementan la lógica de mi aplicación para que las acciones en el controlador API funcionen de esta manera:

//index page def index = { render new IndexApi().index(params) as JSON }

Tengo curiosidad: ¿hay alguna razón para trasladar la lógica de mi aplicación de las clases a los servicios?


Hay tres razones:

  1. Hace que el controlador sea más pequeño -> más fácil de entender y mantener

  2. Te hace la lógica más fácil de probar.

  3. Realmente no desea administrar sus transacciones manualmente.

Si colocara todo en el controlador, tendría que crear el tiempo de ejecución web para poder ejecutar cualquier prueba. Si su lógica está fuera, puede copiar los datos que necesita de la solicitud HTTP y todas las otras fuentes y simplemente llamar al código. Así que la lógica no depende de las sesiones HTTP, solicitudes o cualquier otra cosa que no quieras.

Por ejemplo, para probar los JSP, necesita una solicitud HTTP. Para una solicitud, necesita una sesión HTTPSession y una JSPWriter. Los que necesitan un contexto de sesión. Así que solo para poder ejecutar una sola prueba, necesita configurar e inicializar un montón de clases. Y todas esas son interfaces y las implementaciones son privadas. Por lo tanto, debe implementar los métodos reales (todos los 300) usted mismo. Y es mejor que hagas esto bien o tus pruebas no probarán lo que quieres.


Si desea un comportamiento transaccional, debe poner su lógica en los Servicios. De lo contrario, tendría que cuidarlo usted mismo, lo cual no está en el espíritu de usar Grails.

Como no soy un experto en grails, coloco mis clases "no transaccionales" fuera de la capa de servicio, como clases de constructor, ayudantes y otra lógica que no es transaccional pero que se usa desde la capa de servicio.