Repository pattern
- 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