GORM Data Services VS Grails Services

Question

GORM 6.1 introduced the concept of Data Services. I think of them as auto-generated persistence logic that are checked at compile time. I'm having some confusion as to the following:

1. How are they different from Grails Services (aside from the compile time difference)?
2. Is it possible to still implement my custom business logic inside the GORM Data Services or do I need to maintain two services, one for persistence (GORM) and the other (GRAILS) for other none persistence related business logic (e.g making an external REST request and acting on the response).
3. I noticed grails generate-all Domain generates a Data Service interface for REST profile. This leaves me confused as to whether we can have non persistence related method names in the service.

Update: What I'm asking about is this: gorm.grails.org/latest/hibernate/manual/#dataServices. I'm trying to understand how those are different from this: docs.grails.org/latest/guide/services.html and when to use them.

Answer 1

How are they different from Grails Services (aside from the compile time difference)?

GORM Data Services are Grails services.

Is it possible to still implement my custom business logic inside the GORM Data Services or do I need to maintain two services, one for persistence (GORM) and the other (GRAILS) for other none persistence related business logic (e.g making an external REST request and acting on the response).

You can put business logic in whatever services you like. In general the logic in GORM Data Services should be related to database interactions but that is entirely up to you. If you wanted you could put 100% of your business logic in GORM Data Service instances, though that wouldn't make sense. A GORM Data Service is a Service and you can put whatever you like in it.

I noticed grails generate-all Domain generates a Data Service interface for REST profile. This leaves me confused as to whether we can have non persistence related method names in the service.

You can have non persistence related method names in the service. You can put whatever you want in the service.

The approach I would take is I would use GORM Data Service for database related code and use traditional Grails Services for everything else and inject 1 into the other where appropriate.

Answer 2

I have differentiated your question on the basis of your given points below.

1. All the GORM persistence methods are already compiled (JAR files) but not the service method calls which you are implementing / writing, they gets dynamically compiled as you type and save the code. GORM methods are well optimized.

2. It is possible to write the both your custom business logic and the GORM API calls in a single method, but you need to understand the scenario, if you want write a generic methods for a many other controller calls and also want avoid the complexity, in this case you can write a separate calls for both the above things. for a short custom business logic you can write a code inside the same method.

3. We can also write a non persistence related methods in the same service but, it's up to you. You can also create the separate service for these methods or use an existing other one to avoid any confusion and a complexity.

Note : Services are transactional by default, but can be made non-transactional if none of their methods update the persistence store.