I’ve found myself with a need to move some functionality into the service layer. In this particular case, it relates to an example regarding zend-paginator.
In the example, the service layer is simply an interim stage between the controller and the model. It seems that this is it’s intended role, and under certain circumstances it seems to make good sense.
It raises a few questions for me though.
Firstly, could I not just as easily move the example service code to the controller without any real penalty, and would this not benefit me by removing a layer of code?
Assuming there is a tangible benefit in moving the code to the service layer, what then happens to the rest of my mapper interaction? Does the controller access the service layer for some tasks and the mapper for others, or does the service layer then become a proxy to all mapper interaction?
It seems like for things such as creating a new row from a form, the service layer does not add any value, so it would literally amount to a pass through function at service layer level.
Using it for some tasks seems like it will complicate things later, while using it as a proxy seems like we’re purposely introducing code replication and complexity.
Any clarification on ‘best practice’ would be very helpful.
Moving the code to the controller results in a fat controller. It tightly couples the application with the UI. It makes it hard to perform that action in a different context. A skinny controller handles requests in a specific context by using one or more services to generate a response.
These services define the boundary of the application (domain logic) by interacting with the models in a loosely coupled way that can be integrated into different contexts.
For example, a controller interacts with the service layer in an MVC app. A console wrapper can interact the service layer on the cli. A SOAP or JSON-RPC server can use reflection to expose a service as a webservice API. All of this can be done without duplicating the code.