Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 Response singleton, 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 Service subclass.
  • When a caller (controller) does finally want data, they terminate the fluent API with a getResponse() method which returns the Response singleton, 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:

  • Service subclasses now hide the data they return in a generic bag of data - Response
  • 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 Response class, 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?

share|improve this question
This doesn't have the slightest thing to do with SOA. – Aaronaught Nov 25 '13 at 4:51
Having had a quick look at Laravel's controller documentation, this doesn't seem to be idiomatic in their framework. It almost sounds like Model is missing almost completely (and I'm referring to the Model in terms of MVC, not just the base DTOs and services), some of the controller logic is moved into the data layer (services), and some of the Model logic is moved into the controller. I tend to agree with your concerns, and would want to move away from this architecture (unless some clear design intent is shown). – Daniel B Nov 25 '13 at 4:56
Much appreciated guys. Would either of you like to quickly summarize an answer so that I can close this question? – Omega Nov 27 '13 at 2:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.