The Clean Architecture in php

use
CleanPhp\Invoicer\Domain\Entity\Customer;
use
CleanPhp\Invoicer\Domain\Entity\Order;
use
CleanPhp\Invoicer\Persistence\Hydrator\OrderHydrator;
use
Zend\Stdlib\Hydrator\ClassMethods;
describe(
'Persistence\Hydrator\OrderHydrator'
,
function
() {
beforeEach(
function
() {
$this
->
repository
=
$this
->
getProphet
()
->
prophesize
(
'CleanPhp\Invoicer\Domain\Repository\CustomerRepositoryInterface'
);
$this
->
hydrator
=
new
OrderHydrator(
new
ClassMethods(),
$this
->
repository
->
reveal
()
);
});
describe(
'->hydrate()'
,
function
() {
it(
'should perform basic hydration of attributes'
,
function
() {
$data
=
[
'id'
=> 100
,
'order_number'
=>
'20150101-019'
,
'description'
=>
'simple order'
,
'total'
=> 5000
];
$order
=
new
Order();
$this
->
hydrator
->
hydrate
(
$data
,
$order
);
expect(
$order
->
getId
())
->
to
->
equal
(
100
);
expect(
$order
->
getOrderNumber
())
->
to
->
equal
(
'20150101-019'
);
expect(
$order
->
getDescription
())
->
to
->
equal
(
'simple order'
);
expect(
$order
->
getTotal
())
->
to
->
equal
(
5000
);
});
it(
'should hydrate the embedded customer data'
,
function
() {
$data
=
[
'customer'
=>
[
'id'
=> 20
]];
$order
=
new
Order();
$this
->
repository
->
getById
(
20
)
->
willReturn
((
new
Customer())
->
setId
(
20
));
$this
->
hydrator
->
hydrate
(
$data
,
$order
);

---

Doctrine 2
209
assert
(
$data
[
'customer'
][
'id'
]
===
$order
->
getCustomer
()
->
getId
(),
'id does not match'
);
});
});
describe(
'->extract()'
,
function
() {
// ...
});
});
We’ve removed the test case should hydrate a Customer entity on the Order and updated the
should hydrate the embedded customer data test case to expect the repository to be used to query
for the
Customer
.
We don’t need the hydration of the customer via
customer_id
as that’s not the way Doctrine
provides the data, and Doctrine takes care of the hydration for us.
As Doctrine’s
UnitOfWork
needs to know about all existing entities, otherwise it tries to re-
INSERT them, we’ve updated the hydrator to query for the customer by ID if it encounters an
ID. Another way we could solve this problem is to use the
EntityManager::merge()
method to
make Doctrine aware of the entity.
Let’s make the corresponding changes to the
OrderHydrator
:
// src/Persistence/Hydrator/OrderHydrator.php
namespace
CleanPhp\Invoicer\Persistence\Hydrator;
use
CleanPhp\Invoicer\Domain\Entity\Order;
use
CleanPhp\Invoicer\Domain\Repository\CustomerRepositoryInterface;
use
Zend\Stdlib\Hydrator\HydratorInterface;
class
OrderHydrator
implements
HydratorInterface {
// ...
public function
hydrate
(
array
$data
,
$order
) {
if
(
isset
(
$data
[
'customer'
])
&&
isset
(
$data
[
'customer'
][
'id'
])) {
$data
[
'customer'
]
=
$this
->
customerRepository
->
getById
(
$data
[
'customer'
][
'id'
]
);
}
return
$this
->
wrappedHydrator
->
hydrate
(
$data
,

---

Doctrine 2
210
$order
);
}
}
Now if we start clicking around the application, it should continue to work! It looks, from a UI
and interaction perspective, like nothing has changed. Under the hood, however, we’re using an
entirely different database architecture.
That’s very powerful.
This would make a good place to commit your code to source control.
If you’re just reading, but want to see the code in action, you can checkout the tag
12-doctrine-hydrators:
git clone https://github.com/mrkrstphr/cleanphp-example.git
git checkout 12-doctrine-hydrators
Summary
The application is now using Doctrine for its underlying database abstraction layer. We didn’t
have to change any application code in the process, as the application code relied only on
interfaces and dependency injection. Since what is injected works as it should, the application
continues to function without further modifications.
We also have the benefit of having to write much less code to get database interaction to work.
In most cases, we’re simply proxying off to Doctrine’s
EntityManager
to do the work for us.

---