The Clean Architecture in php

class
CustomersController
extends
AbstractActionController {
public function
indexAction
() {
return
[
'users'
=>
$this
->
customerRepository
->
getAll
()
];
}
}
This is a simple GET request to an index action (maybe
/customers
) that simply lists all
customers. The controller uses the dependency injected
CustomerRepository
(not shown) and
its
getAll()
method to retrieve all the customers.
²³
http://silex.sensiolabs.org/

---

Framework Independence
79
Obviously we’re going to have more complex actions than
indexAction()
, but the point is that
we want to pass all of the logic and processing to our Domain Services layer, and keep the
controllers as small, tight, and single purposed as possible.
Views
Your view layer should be primarily composed of HTML, JavaScript and CSS. There should be
no business logic contained within the views; only display logic. These views should be mostly
transferable when switching frameworks. The only questionable part is the means by which data
is presented to the view from the controller, which will probably vary by framework.
The big thing to watch out for is view services, view helpers, and/or view plugins, which many
frameworks provide. These components help generate common or recurring HTML, such as links
or pagination, or even forms (which we’ll talk about next). The method by which these exist will
likely vary wildly by framework, and could cause quite a headache if they were very heavily
relied on.
If you’re writing your own helpers, which many frameworks allow you to do, make sure that
you’re writing the bulk of the code without relying on the framework, so that you can easily
move this helper to a new framework. If possible, also consider writing interfaces and/or an
adapter that turns your helper into something the framework expects.
Do as much as you can to make leaving the framework easy.
Another option would be to forgo your framework’s built-in view layer and use a third party
library, such as
Plates²⁴
. This will allow you to keep your view layer intact when switching
frameworks.
Forms
In my experience, forms have been one of the hardest things to deal with in projects. Doing
forms cleanly and independent from the framework is near impossible. Again, we can write a
bunch of adapters to abstract the usage of the framework, but that will almost certainly negate
the time savings given by the framework.
The biggest rule is to make sure that no business logic whatsoever exists within the form code.
Remember: business logic belongs in the Domain layer. Aside from validation rules and filtering,
no logic should be contained within the forms.
Outside of that: just use them. If the bulk of your work when switching frameworks is porting
the forms, you’re in pretty good shape.
Another solution to try would be to use some third party form library, so that you’re not coupled
to your framework’s form classes. Something such as
Aura.Input²⁵
from the Aura components
would suffice, and allow you to keep that code when switching frameworks. Some form libraries
are light enough that you might even be able to write an adapter around them, but only do so if
you’ll be able to accomplish that quickly.
²⁴
http://platesphp.com/
²⁵
https://github.com/auraphp/Aura.Input

---

Framework Independence
80