The Clean Architecture in php

class
User
{
public
$id
;
public
$alias
;
public
$fullName
;
public
$email
;
}
How exactly does data get into these variables from the database, and how do we save changes
we make back to that database? If we add in methods and mechanisms to this
User
class to persist
our data to the database for us, we’re then making it very hard to test and switch data sources
or database abstract layers later. We’ll cover various approaches and solutions to this problem in
Database Independence
.
Model Layer vs Model Class vs Entities
The solution to this problem is to realize there’s a difference between the Model Layer of MVC,
and the Model Class. What we have in our example above is a Model class. It’s a representation
of the data. The code responsible for actually persisting that data to the database storage is part
of our model layer, but should not be part of our model class. We’re mixing concerns there. One
concern is a representative model of the data, and the other is the persistence of that data.
From now on, we’re going to refer to the actual model class, like the one above, as an entity.
Entities are simply representational states of things that have identities and attributes unique to
that identity. For instance, an Order, User, Customer, Product, Employee, Process, Quotes, etc.,
can all be entities.
We’re also going to stop referring to the model layer as the persistence layer. The persistence
layer is simply the layer of code that is responsible for persisting data, entities, back to the data
store, as well as retrieving entities from the data store based on their identity.
From here-forth, you can pretend like the word model doesn’t exist, and with that, we can drop
all baggage of the obese model.