The Clean Architecture in php

class
UserController
extends
AbstractController {
public function
indexAction
() {}
public function
viewAction
() {}
public function
updateAction
() {}
}
This example controller has three actions:
•
indexAction
is responsible for listing all Users
•
viewAction
is responsible for viewing a User
•
updateAction
is responsible for updating a User
On a specific request, let’s say the view customer request, the corresponding action will be called,
which would process the request and prepare the required view. This might look something like:

---

MVC, and its Limitations
65
public function
viewAction
() {
$id
=
$this
->
params
(
'id'
);
$user
=
$this
->
repository
->
getByid
(
$id
);
$view
=
new
View();
$view
->
setFile
(
'users/view.phtml'
);
$view
->
setData
([
'customer'
=>
$user
]);
return
$view
;
}
This pseudo-controller action in this sample code retrieves the passed ID from some mechanism,
then uses the stored
UserRepository
to retrieve that user. Finally, it instantiates a new view, sets
the view file to render, and passes the data off using
setData()
.
Here, we can see that the controller only cares about responding to requests. It uses the model
layer to retrieve data, and then passes it off to the view layer for processing and display.
Routing
This all starts to make much more sense when you consider how routing works in web-based
MVC applications. We tend to lean towards using clean URLs these days, where our URI looks
like this:
/
users
/
view
/1
Or, if you’re defining RESTful URIs:
/
users
/1
This is a URI that would route to the
UserController
’s
viewAction
in our examples above.
Traditionally when routing clean URLs to controllers, the first part of the URI,
/users
maps to
the controller,
UsersController
in our example, while the part,
/view
, maps to the action, which,
of course, is the
viewAction
.
This isn’t always the case, however. Must frameworks allow routing to be whatever you make
it, such that any URI can map to any controller or action.
Some frameworks make this explicit and do not require any additional setup. They simply map
the URI to a corresponding controller and action. Most modern frameworks require you to setup
some sort of routing table that tell it which URIs map to which portions of code.
In Zend Framework 2, that looks something like this:

---

MVC, and its Limitations
66
return
[
'router'
=>
[
'routes'
=>
[
'user'
=>
[
'type'
=>
'Literal'
,
'options'
=>
[
'route'
=>
'/users'
,
'defaults'
=>
[
'controller'
=>
'App\Controller\Users'
,
'action'
=>
'index'
]
],
'may_terminate'
=>
true
,
'child_routes'
=>
[
'view'
=>
[
'type'
=>
'Segment'
,
'options'
=>
[
'route'
=>
'/view/[:id]'
,
'defaults'
=>
[
'action'
=>
'view'
],
'constraints'
=>
[
'id'
=>
'[0-9]+'
,
]
]
]
]
]
]
]
];
This long-winded block of code defines two routes,
/users
, which routes to
UsersController::indexAction()
,
and
/users/view/[:id]
, which routes to
UsersController:viewAction()
. Both are
GET
re-
quests.
You can see how flexible this can be in defining routes as they don’t have to match the controller
structure whatsoever. But it is pretty verbose.
Laravel, on the other hand, takes a much simpler approach to routing:
Route
::
get
(
'user/view/{id}'
,