I know the subject is quiet epic. Let me put it straight that lots of time I have heard that keep the controllers light, do not put service logic inside those controllers, simply receive the request from those controllers and pass to internal service to do the heavy lifting and respond back using these controllers.
Now my question in regards to servicestack. Do we need to follow the same practice here as well. Or we are good to put our logic in our xxxService which is inherited from Service base class. Is it ok to do the heavy lifting and orchestration etc here directly inside this xxxService.
Otherwise kindly advise and if my question is useless kindly ignore.
Definitely don’t need to abstract logic from the Services implementation as the clean message-based Request / Response DTO already makes it reusable and endpoint agnostic.
Only time you would want to extract logic into different classes is for DRY and you had multiple services sharing the same logic, of which my preference is to first minimize the use of any additional IOC dependencies by using extension methods first (e.g. if the logic requires access to the database I’d add App extension methods off IDbConnection). If the logic requires several dependencies, at that point I may consider encapsulating it behind another class that’s injected to all Services that needs it.
Note: this doesn’t apply if you need to use the entire service logic (e.g. if you’re creating composite services) as you can easily invoke other services with the Service Gateway.
@mythz Thank you so much such a relief that I can use the logic and do all the orchestration in the xxxService file which is inherited from the Service base class.