Il primer del modello di repository

Ogni volta che stai lavorando a un progetto più ampio basato su WordPress, le probabilità che lavorerai con più di una singola fonte di dati, ovvero il database di WordPress, sono più alte del normale. Ad esempio, potresti lavorare su un progetto che deve coordinare le informazioni da:

• il database di WordPress,
• un sistema di biglietteria di help desk,
• un sistema di importazione dei contenuti,
• un’altra API di terze parti,
• e possibile di più.

E quando ciò accade, può diventare un po’ complicato scrivere codice che renda facile recuperare le informazioni da quei luoghi diversi. Questo è ciò di cui gli sviluppatori di solito parlano quando si riferiscono alla gestione dei "livelli" nella loro applicazione. Cioè,

• ci sono livelli per la presentazione delle informazioni all’utente,
  livelli per la gestione della logica aziendale (o logica di dominio),
• livelli per la comunicazione con le API,
• e livelli per la memorizzazione dei dati.

Onestamente, non è necessario disporre di una varietà di archivi di dati da guardare per creare un livello che semplifichi l’invio e il recupero dei dati dal database, proprio quando è più comune. Puoi lavorare altrettanto efficacemente con un singolo archivio dati, come il database di WordPress, quando implementi il ​​modello di repository.

Indipendentemente da ciò, se stai creando un sito Web, un’applicazione Web o un plug-in più grandi, l’implementazione del modello di repository è qualcosa che può pagare dividendi in termini di manutenzione, chiarezza del codice e separazione delle preoccupazioni.

Ma come potrebbe essere implementato all’interno di WordPress? Non è terribilmente impegnativo, ma prima di tutto vale la pena rivedere un primer del repository prima di passare a qualsiasi codice.

Un primer per pattern di repository

Prima di esaminare un’effettiva implementazione in WordPress, è importante capire cos’è il repository, come è definito, cosa offre e una sua implementazione generica. Condividerò alcune ulteriori letture alla fine dell’articolo, ma fino ad allora tratterò la mia opinione generale sullo schema qui.

Innanzitutto, un’implementazione di questo modello può diventare più complicata del necessario per i principianti. Questo non vuol dire che lo schema reale non valga la pena di essere compreso, ma se stai solo cercando di bagnarti con questo, non sono un fan di gettare i lettori nel profondo. Non credo sia il modo migliore per imparare.

Invece, vale la pena scomporre il problema e ricostruirlo in qualcosa di un po’ più elegante. Quindi è quello che ho intenzione di fare.

Una parola sul disaccoppiamento

Quando si parla di programmazione orientata agli oggetti, si parla spesso dell’idea di "disaccoppiare" parti del sistema. Se hai familiarità con l’ accoppiamento e la coesione, allora sai perché.

In caso contrario, basti sapere che più accoppiati sono i componenti del tuo sistema, più difficile sarà cambiarli. Sanno troppo l’uno dell’altro. Cioè, se si modifica uno degli aspetti del sistema, è probabile che si verifichi una cascata o un impatto su un’altra parte del sistema che non avresti mai voluto che accadesse. Quindi ti rimane quando devi dedicare molto più tempo a riparare tutti questi altri "punti di contatto" nel sistema che non dovrebbero essere necessari.

L’implementazione di varie strategie, come il modello di repository, può aiutare a disaccoppiare parti del sistema. Caso in questione: il livello di presentazione non sa come sia l’organizzazione del datastore sottostante. Non ha bisogno di conoscere SQL. Non ha bisogno di sapere che è un database. Invece, ha solo bisogno di sapere come parlare con il repository.

Bello, vero?

Ciò significa che puoi sostituire l’archivio dati di back-end e, supponendo che la tua API sia solida; la tua applicazione continuerà a funzionare senza modifiche minime. Ed è questo che significa essere veramente disaccoppiati.

Un’implementazione del modello di repository

Quindi, che aspetto ha il modello del repository? Come con la maggior parte dei modelli di progettazione, esiste una forma generica del modello, e questo è sempre utile, ma penso che aiuti anche quelli di noi che lavorano in WordPress a vedere come potrebbe funzionare nel contesto, sai, di WordPress. 

Quindi, prima, voglio scomporre il modello stesso e poi fornire un esempio di come potrebbe apparire quando si lavora con WordPress.

Un implementazione generico del modello di repository

L’effettiva implementazione del pattern del repository è piuttosto semplice. In effetti, non sono mai sicuro che sia così utile perché mostra solo come interagiscono tra loro gli archivi dati, il repository e il resto dell’applicazione.

Non fraintendetemi: sono tutto per i modelli concettuali di come sono organizzate le cose. Personalmente, mi aiuta a pensare alla struttura di un’applicazione quando la costruisco, ma se è troppo generica, non è di grande aiuto.

Ma per arrivare a un attrezzo concreto, dobbiamo cominciare da qualche parte, giusto? Quindi inizierò dal livello più alto possibile e lavorerò verso il basso.

Come puoi vedere nell’immagine sopra, hai un paio di archivi dati che vengono tutti letti tramite il repository, quindi l’applicazione interroga il repository che, a sua volta, recupera le informazioni dal datastore.

Sì, ci sono opzioni per memorizzare nella cache le informazioni, invalidare la cache e tutte quelle cose divertenti. Ma è al di fuori dell’ambito di un primario del repository. Quindi non ho intenzione di seguire quel particolare percorso per ora. Magari in un prossimo post (se questo dovesse esserti utile).

Il modello di repository in WordPress

Detto questo, diamo un’occhiata a un’implementazione di base di come potrebbe apparire in un’installazione standard di WordPress. Cioè, tutto ciò che abbiamo è l’archivio dati. Non stiamo comunicando con nient’altro, ma vogliamo assicurarci che tutto ciò che si interfaccia con il database o l’API sia gestito dal repository

Questo assomiglierebbe a questo:

Come potrebbe apparire con WordPress

E questo può essere ulteriormente astratto. Forse c’è un repository di post o un repository di utenti. Personalmente, sono un fan dell’avere un repository per ogni tipo di entità perché aiuta a contenere la logica aziendale correlata senza creare quelle grandi classi che sanno tutto (e inutilmente).

Quindi questo potrebbe assomigliare a questo:

Un pacchetto di repository

Quindi saliamo di un altro livello e diciamo che stai lavorando con l’API di Twitter, l’API ZenDesk, l’API utente di WordPress e l’API Post di WordPress. Allora cosa? Ci sono più repository.

Forse sono contenuti nel loro spazio dei nomi (come dovrebbero essere), forse stanno implementando un’interfaccia comune (per la quale esiste un caso per questo), ma durante il tempo di sviluppo, penso che sia importante indicare esplicitamente quale repository stai usando quindi per essere il più chiaro possibile.

Cioè, non usare un generico e lascia che il runtime lo capisca:

$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );

Invece, sii esplicito:

$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );

Questo potrebbe sembrare molto. Non so se lo si verifica, ma c’è una strana sensazione nella programmazione orientata agli oggetti in cui vogliamo creare le classi piccole e mirate ma crea molti file.

Quindi hai questi file ben impostati, ognuno dei quali sta facendo qualcosa di piccolo e mirato. Non lasciare che il numero di file che compongono un progetto dia l’impressione di avere un’architettura scadente.

Conclusione

Questo è il primer sul pattern del repository. Naturalmente, c’è del codice che va di pari passo con questo, ma prima di immergermi in quella parte, perché il codice è dove le cose che si perdono facilmente nella traduzione, volevo assicurarmi di aver contribuito a fornire un’illustrazione per sviluppare un modello concettuale di come funziona il modello.

Da qui, possiamo iniziare a parlare di un’implementazione del pattern. Quindi nel prossimo post o nei prossimi due post, farò esattamente questo.

Nel frattempo, non esitate a lasciare commenti o domande su ciò che abbiamo trattato qui.

Lettura correlata

• Il modello di repository tramite 8th Light
• Il modello di repository tramite MSDN
• Un’implementazione del modello di repository