Vantaggi del modello di repository: perché dovremmo considerarlo
Ieri ho fornito un primer sul pattern del repository. In breve, è uno di quei modelli che penso che chiunque lavori su un middleware basato su WordPress dovrebbe capire.
Quando si fornisce un primer su un modello come questo, può essere difficile rendere giustizia al modello quando è necessario:
- introdurlo,
- spiega come funziona,
- coprire i benefici,
- e fai una piccola demo.
Ma il vero vantaggio del repository risiede non solo nell’astrazione del livello dati dal resto dell’applicazione, ma anche nel fatto che può (o dovrebbe) essere facilmente scambiato con vari archivi di dati senza modificare l’API.
Ad esempio, in un caso, potrebbe essere necessario recuperare i dati dal database di WordPress, in altri casi potrebbe essere necessario recuperare qualcosa da un’API di terze parti o forse c’è un altro posto da cui è necessario recuperare i dati.
Indipendentemente da ciò, l’idea alla base del modello di repository è che qualunque cosa si trovi dietro non ha importanza fintanto che l’API che fornisce funziona per il livello dell’applicazione che vi chiama.
E poiché abbiamo trattato un primer sul pattern del repository, diamo un’occhiata ad alcuni dei vantaggi del pattern del repository e come possiamo implementarlo nel contesto dei progetti WordPress.
Vantaggi del modello di repository
Ci sono alcuni modi per iniziare a spiegare lo schema, quindi inizierò con un diagramma semplice:
I vantaggi del modello di repository includono l’astrazione dell’archivio dati
Nota nell’immagine sopra, ci sono tre componenti principali:
- la logica di dominio (o la logica di business) che ho etichettato come "App",
- il deposito,
- l’archivio dati,
Per quanto riguarda l’applicazione, le regole aziendali rimarranno sempre relativamente coerenti. Almeno dovrebbero, giusto?
Il repository è ciò che funge da mezzo di comunicazione tra la logica aziendale e l’archivio dati.
Ora l’archivio dati può essere un database, forse un insieme di file (che non consiglierei), un’API di terze parti, un elenco di informazioni recuperate da un’altra applicazione e così via.
Il punto è che il repository fornirà un’API pulita in cui la logica aziendale può scrivere e leggere (e altro su questo in un momento) senza preoccuparsi dei dettagli di dove stanno andando i dati o di come stanno tornando.
Questo è il lavoro del repository. Ed è questo che rende importante avere un’API coerente ed è ciò che è importante per assicurarsi che disponga dei dettagli di implementazione dell’archivio dati con cui sta interagendo.
Sull’accoppiamento
Oltre ad avere la tua applicazione adeguatamente segmentata, il modello di repository avvantaggia l’architettura in quanto aiuta a disaccoppiare le parti della tua applicazione.
Cioè, la logica aziendale non sa nulla su come o dove vengono archiviati i dati. Sa solo che può scriverlo e recuperarlo e può farlo utilizzando un’API pulita.
Il repository è responsabile della comunicazione di detto archivio dati per orchestrare la serializzazione e il recupero, ma deve fornire un’API coerente, quindi il livello dati non deve eseguire alcuna ginnastica sintattica per leggere e scrivere le sue informazioni.
Dettagli di implementazione
Fino a questo punto, ho rappresentato il repository come una classe concreta.
Il fatto è che un’applicazione avrà probabilmente più repository. E per questo motivo, è una buona idea disporre di interfacce che ogni repository può implementare.
Questo è il modo in cui definisci il contratto dei metodi che il repository fornirà. Ed è così che puoi assicurarti che ogni repository sia connesso all’archivio dati appropriato.
Un’implementazione dell’interfaccia per più repository.
Quindi supponiamo che la tua applicazione debba comunicare con il database di WordPress e con un’API di terze parti.
Idealmente, l’interfaccia fornirebbe un insieme comune di metodi, ma i dettagli di implementazione varierebbero in base al repository perché ogni repository avrà le credenziali e la capacità necessarie per comunicare con l’archivio dati.
Tuttavia, l’avanzamento all’interfaccia è ciò che conferisce al modello la sua potenza. La logica del dominio non deve preoccuparsi di come vengono salvate le informazioni o di come vengono recuperate. Chiama semplicemente i metodi definiti nell’interfaccia e l’oggetto necessario si prende cura di esso.
Chiama semplicemente i metodi definiti nell’interfaccia e l’oggetto necessario si prende cura di esso.
Come sarebbe in WordPress?
Questa è una buona domanda (e no, non me la sono inventata solo per rispondere da solo 🙂), e può essere difficile dare un ottimo esempio perché gran parte di ciò che facciamo interagisce direttamente con il database di WordPress.
Ciò non significa che non ci siano astrazioni che possiamo utilizzare come post, pagine, utenti o qualsiasi altro tipo di post personalizzato che scegliamo di creare.
Ma WordPress fornisce un’API per gran parte di questo. Riesco a vedere un caso in cui, ad esempio, un utente con campi aggiuntivi che sono stati aggiunti potrebbe trarre vantaggio da un repository utente.
Oppure un tipo di post personalizzato con molti metadati potrebbe anche trarre vantaggio da un repository avendo i dettagli incapsulati nel repository.
Un esempio di alto livello
Supponiamo, ad esempio, di avere un tipo di post personalizzato per un evento e che l’evento abbia un titolo e una descrizione che si adatterebbero naturalmente al titolo e al contenuto del post.
Ma poi ha metadati sulla sua posizione, la sua ora di inizio, la sua ora di fine e così via. Questo potrebbe anche essere incapsulato dal repository in modo da poter avere un oggetto Event, passarlo al repository e quindi lasciare che il repository invii le informazioni nella posizione corretta nel database.
E lo stesso vale per il recupero delle informazioni: sa dove trovarle, come popolare un oggetto Evento e quindi restituirlo al chiamante.
Di nuovo in pista
Ma tutto questo parlare di un evento sta diventando un po’ fuori tema, quindi forse continuerò a parlarne e di come si adatta al repository in un post di follow-up. Chiaramente, quando si parla di questo, c’è molto da coprire.
Preferirei prenderlo a piccoli passi
In breve, se si dispone di un repository di eventi è probabile che si disponga di un oggetto Evento o di un’entità Evento. E come questo si adatta a WordPress, tipi di post personalizzati, metadati e così via introduce un livello di complessità che può sembrare scoraggiante all’inizio, ma alla fine si ripaga quando si lavora con un’applicazione web più grande.