I'm going to set out a scenario/pattern I've encountered and then I have a few questions pertaining to it.
During an MVC request in a web framework (PHP, Laravel in my case), if I have an abstract base class
Service where subclasses:
- Do not return values
- Deposit the result of their work into a common
Responsesingleton, even across multiple service classes.
- Never throw exceptions but instead report error situations as another bag of values in the response singleton.
- Offer a fluent API to chain calls to a single
- When a caller (controller) does finally want data, they terminate the fluent API with a
getResponse()method which returns the
Responsesingleton, with no idea of what might be in it or what transpired and when over the course of the prior chained calls.
Would I have an anti-pattern on my hands here? My concerns being:
Servicesubclasses now hide the data they return in a generic bag of data -
- Because of the desire to implement a fluent API, services are now more or less a relocation of controller code, rather than portable business logic. In order to do fluent calls, the methods all have to exist on the same instance which means you are now forced to mix unrelated functionality into the same instance.
- Callers of a service class (typically controllers and other services) are now coupled to the structure of the
Responseclass, rather than being provided with the data they request (say an ORM collection, or a simple language collection type), they're now having to perform extra work rather than simply deal with pure, returned data.
- Separation of concerns when creating inter-dependent services, especially during error situations whereby the scope of the failure is lost.
- Loss of the ability to detect accidental circular dependencies between services via dependency injection
- Is this "SOA"?
Are there any more risks in this design or if it's a known one, are there advantages to this pattern over simply writing plain classes that return the domain data directly for a service layer?