The Clean Architecture in php

namespace
MyApp\Controller;
class
Customers
{
public function
index
() {
return
[
'users'
=>
$this
->
customerRepository
->
getAll
()
];
}
}
With an adapter that looks something like:

---

Framework Independence
78
class
CustomersController
extends
AbstractActionController {
protected
$controller
;
public function
__construct
(Customers
$controller
) {
$this
->
controller
=
$controller
;
}
public function
indexAction
() {
return
$this
->
controller
->
index
();
}
}
This seems entirely like overkill. All we’re doing is simply wrapping one class in another just to
call a method and pass it through. It’s a bunch of busy work just to claim we’re highly decoupled?
If you’re using a lighter framework, like
Silex²³
, this might be a little easier as controllers are a
developer concept, not a framework concept proper. Those controllers only become as coupled
as you make them.
Keep Your Controllers Small
Our best bet when dealing with controllers is to make sure we actually minimize the controller
code. We want to follow very closely the
Single Responsibility Principle
we discussed previously.
Each controller, and each action in the controller, should have as little code in it as possible.
Controllers should be thought of as response factories. They are responsible for building a
response based on the input (the HTTP request). All logic should be passed off to either Domain
Services or Application Services for processing, and the data returned from them loaded into a
response and returned.
Ruby on Rails was big on the mantra of “fat model, skinny controller,” and that is at least partially
sound. Having a skinny controller is very important. Having a fat model? Well, that depends on
what “fat” and “model” mean to you. We’ll discuss this in depth in
Database Independence
.
Having a skinny controller means that a controller doesn’t really do much. Let’s take this
controller action, for example: