Repository Pattern - Un buon design al servizio della testabilità. Slides presentate al PUG Milano il 12/04/2017

1. Repository Pattern
Un buon design al servizio della testabilità

2. Mi presento
Christian Nastasi
Software Architect & Technical Coach
Sviluppo Software dal 1999
Esperienza di quasi 2 anni a Londra
Email: christian.nastasi@gmail.com
Linkedin: /in/cnastasi/

3. Disclaimer
● Non possiedo la verità assoluta, questo è solo uno dei
tanti approcci possibili
● Fra 1 anno probabilmente scriverò codice in maniera
completamente differente
● Questo talk era stato ideato sotto forma di workshop,
per questioni di tempistiche è stato ridotto e certe
tematiche potrebbero essere incomplete.

4. A Repository mediates between the domain and
data mapping layers, acting like an in-memory
domain object collection.
Client objects construct query specifications
declaratively and submit them to Repository for
satisfaction.
Objects can be added to and removed from the
Repository, as they can from a simple collection of
objects, and the mapping code encapsulated by the
Repository will carry out the appropriate
operations behind the scenes.
Martin Fowler
Repository Pattern: Definizione
Un Repository fa da intermediario tra il dominio
(business logic) ed il layer di persistenza, agendo come
una collezione di oggetti di dominio, salvati in
memoria.
Gli oggetti “cliente” costruiscono le query
dichiarativamente e le inviano al Repository per essere
eseguite.
Gli oggetti possono essere aggiunti e rimossi nello
stesso modo in cui viene fatto per una collezione di
oggetti. Il codice relativo alla persistenza è incapsulato
all’interno del repository, che si occuperà di eseguire le
operazioni appropriate “dietro le quinte”
Martino Cacciatore di uccelli

5. Repository Pattern: Definizione
Un Repository è un’astrazione che ci permette di separare i dati
da come vengono utilizzati a come vengono memorizzati.
L’astrazione è quella della collezione di oggetti con interfaccia
CRUD.

6. Repository Pattern: Definizione
Le query vanno scritte in modo dichiarativo: significa che
dobbiamo indicare soltanto cosa vogliamo ottenere.
Il come è compito del Repository, che incapsula al suo interno le
logiche di persistenza.

7. Repository Pattern: Esempio di interfaccia
interface EntityRepository
{
public function get (int $id):?Entity;
public function getBy (Criteria $criteria):Iterator;
public function getAll():Iterator;
public function save (Entity $entity);
public function delete (Entity $entity);
public function exists (Entity $entity):bool;
}

8. Caso di studio: Blog MVP
- As a user I want to publish a post
- As a user I want to see all my posts
- As a user I want to publish a comment on a post
- As a user I want to see all the comments of a post

9. Step 0: Codice Monolitico
- Classe monolitica
- Logica e persistenza mischiate nello
stesso posto
- Non si possono usare i mock
- Necessità di un database di test

10. Step 1: Dividiamo le responsabilità
+ Codice suddiviso logicamente
- Logica e persistenza mischiate nello
stesso posto
- Non si possono usare i mock
- Necessità di un database di test

11. Step 2: Separiamo la logica dalla persistenza
+ Codice suddiviso logicamente
+ Logica e persistenza separate
- Non si possono usare i mock
- Necessità di un database di test

12. Step 3: Incapsuliamo i dati in modelli
+ Codice suddiviso logicamente
+ Logica e persistenza separate
+ Si possono usare i mock
- Necessità di un database di test

13. Entità
Un’entità è un modello che rappresenta un oggetto di dominio e che può
essere identificato univocamente attraverso un id.
Istanze differenti dello stesso oggetto ma con un id identico rappresentano la
stessa entità e sono pertanto uguali.

14. Step 4: Refactoring dei Manager
+ Codice suddiviso logicamente
+ Logica e persistenza separate
+ Si possono usare i mock
- Necessità di un database di test

15. Step 5: Refactoring dei Repository
+ Codice suddiviso logicamente
+ Logica e persistenza separate
+ Si possono usare i mock
+ Necessità di un database di test

16. Step 5: Refactoring dei Repository

17. Step 5: Refactoring dei Repository

18. Vantaggi
+ Si può mutare il layer di persistenza senza incidere sul funzionamento
della logica
+ Utilizzando un Repository In-memory i tempi per eseguire i test di unità
si accorciano e non c’è bisogno di ripulire il DB ogni volta.
+ Incoraggia un design DRY (don’t repeat yourself)
+ Il layer di persistenza potrebbe essere di qualsiasi natura, anche remoto
(Utile in una logica a microservices)

19. Grazie!
Commenti o domande? Contattatemi
christian.nastasi@gmail.com