<div dir="ltr"><div>Ciao a tutti,</div><div>volevo chiedervi un consiglio su come impostare una determinata sezione di un progetto su cui stiamo lavorando.</div><div>Perdonatemi la lunghezza ma cerco di spiegarmi al meglio per inquadrarvi bene la situazione.</div><div>Il cuore del problema è il Data Mapper Pattern e come gestire al meglio le classi che entrano in gioco.</div><div><br></div><div>Premetto che non ho esperienze di DDD o particolari esperienze con ORM e similari quindi alcune cose che dirò potrebbero sembrarvi stupide o completamente senza senso.</div><div><br></div><div>Nell'ottica di ristrutturare le classi che gestiscono gli "oggetti" su cui operiamo, ho iniziato a sviluppare un insieme di classi che si avvicinassero più o meno al data mapper pattern. Quindi ho le mie entità che sono POPOs con i loro metodi necessari per la logica delle entità stesse. Queste classi non hanno nessuna conoscenza del database (anche se hanno tra le proprietà gli id che a ben vedere con le entità c'entrano poco o niente).</div><div>Ho poi costruito le mie classi repository che vanno a fare avanti e indietro tra db e entità (idratano gli oggetti e allo stesso tempo fanno la persistenza mappando le proprietà cn i campi del db).</div><div><br></div><div>Non ho usato ORM come Doctrine (che tra l'altro non ho mai usato) o similari perchè l'applicazione che stiamo usando purtroppo è una legacy application in cui i dati sono sparsi tra due DB differenti (sql server + mysql). Ho preferito iniziare a costruire una semplice soluzione in casa piuttosto che sbattere la testa con una libreria che non sono sicuro che possa coprire il nostro caso.</div><div>L'approccio che ho usato, in sè, ci ha portato dei vantaggi, soprattutto per quanto riguarda il salvataggio e la persistenza dei dati che ovviamente ora sono in un unica classe ecc ecc.</div><div><br></div><div>I problemi che sto avendo sono di natura architetturale e ora cerco di entrare nel merito.</div><div><br></div><div>Il progetto su cui stiamo lavorando è legato alla gestione di artisti musicali e dati correlati.</div><div><br></div><div>Nel nostro caso abbiamo diversi livelli di dati differenti sparsi su N tabelle che rappresentano l'artista. </div><div><br></div><div>PUNTO 1: DATI CHE DEFINISCONO L'ARTISTA</div><div><br></div><div><span class="" style="white-space:pre">       </span>a. dati di base (id, nome, tipo)</div><div><span class="" style="white-space:pre">   </span>b. dati estesi (nazionalità, data di nascita / morte, biografia, discografia ecc)</div><div><span class="" style="white-space:pre"> </span>c. aliases (nomi alternativi, nomignoli ecc)</div><div><span class="" style="white-space:pre">       </span>d. relazioni con altri entità di tipo artista (membri della band/ band con cui l'artista ha suonato ecc)</div><div><span class="" style="white-space:pre">      </span>e. relazioni con altre entità (genitori, fratelli ecc)</div><div><span class="" style="white-space:pre">    </span>f. meta dati vari (profilo deezer, sito ufficiale, fb, tw, g+ ecc)</div><div><span class="" style="white-space:pre"> </span>g. indice di copertura (identifica quanto l'artista è coperto dai nostri contenuti)</div><div><br></div><div><br></div><div>PUNTO 2: ENTITA' ESTERNE CHE IN LINEA TEORICA SONO RELAZIONABILI ALL'ARTISTA</div><div><br></div><div><span class="" style="white-space:pre">     </span>- articoli / news che lo riguardano</div><div><span class="" style="white-space:pre">        </span>- recensioni</div><div><span class="" style="white-space:pre">       </span>- videoclip</div><div><span class="" style="white-space:pre">        </span>- foto</div><div><span class="" style="white-space:pre">     </span>- citazioni</div><div><span class="" style="white-space:pre">        </span>- ...</div><div><br></div><div><br></div><div>Nel mio caso specifico l'entità artista può essere definita completamente con il punto 1. E' possibile costruire un artista istanziando un oggetto di tipo Artist. </div><div><br></div><div>L'oggetto è un grafo in cui ho delle proprietà di base che coprono i punti a/b e ho delle collezioni di altri oggetti (ognuno definitio a parte) che gestiscono:</div><div><span class="" style="white-space:pre"> </span>- Alias punto c</div><div><span class="" style="white-space:pre">    </span>- Meta punto f</div><div><span class="" style="white-space:pre">     </span>- Relazioni punto d/e</div><div><span class="" style="white-space:pre">      </span>- Copertura e ranking punto g (..ehm..)</div><div><br></div><div>Il tutto mi va bene, ho il typehinting, la logica sta nelle classi e ok.</div><div><br></div><div>L'ArtistRepository è un oggetto piuttosto grande che manda avanti e indietro questi dati (complessivamente) tra tutte le tabelle coinvolte. </div><div>Ha classici metodi pubblici da repository:</div><div><span class="" style="white-space:pre"> </span>- findById</div><div><span class="" style="white-space:pre"> </span>- persist (gestisce sia insert che update)</div><div><span class="" style="white-space:pre"> </span>- remove</div><div><span class="" style="white-space:pre">   </span>- ...</div><div><br></div><div>Questo è ok ma ora mi si presentano diversi problemi che non so bene come risolvere. Questi i primi che mi vengono in mente:</div><div><br></div><div>1) PROBLEMI DI PERFORMANCE</div><div><br></div><div>Se uso questo repository così com'è nell'applicazione ho dei problemi di performance (lasciando da parte il caching a cui arriverò dopo). Immaginiamo una scheda degli Oasis, se prendo gli oasis tramite repository e voglio rappresentare anche tutti i vari componenti, andrò a prendermi le relazioni, da qui creerò altri oggetti artista completi per poter semplicemente mostrare a video i loro nomi. Risultato, se per un artista mi ci vogliono 7-10 query nel DB, qui le moltiplico per tutti i componenti per nulla.</div><div><br></div><div>Allora ho pensato a questa cosa: il repository potrebbe avere dei metodi -con fluent interface eventualmente- del tipo withBaseData / withMeta ecc che dicono al repository quali parti dell'oggetto Artista andare a recuperare.</div><div>Quindi il mio $repo->fetchById() potrebbe diventare al caso $repo->withBaseData()->withRelations->fetchById() per andare a prendere un artista con i suoi dati di base ma anche le relazioni e nient' altro.</div><div>Il problema è che se poi lanciassi un persist mi cancellerebbe tutti i dati che non ho recuperato xè per il repository quell'artista non ha alias metadata o altro.</div><div>Quindi dovrei tenere traccia all'interno dell'entità artista di quali "parti" sono state idratate e quali no. In modo che all'atto del persist il repository può verificare cosa deve toccare e no.</div><div><br></div><div>Questo mi genera una serie di perplessità:</div><div><span class="" style="white-space:pre">     </span>- dal punto di vista dell'entità il concetto di cosa è stato idratato o meno non ha assolutamente senso</div><div><span class="" style="white-space:pre">      </span>- l'aggiunta di metodi come withBaseData o withRelations rende il repository troppo specifico e difficilmente astraibile in un'interfaccia repository generica. </div><div><span class="" style="white-space:pre">          </span>- questo mi blocca nel caso volessi usare un decorator per aggiungere un livello di logging piuttosto che di caching tramite file / redis ecc</div><div><span class="" style="white-space:pre">              </span>- potrei certo costruire un'interfaccia ad hoc ma sto cercando di capire se può essere ripensato il tutto per salvare capra e cavoli</div><div><br></div><div>2) PROBLEMI DI RECUPERO DATI ESTERNI</div><div><br></div><div>In questa situazione come è meglio recuperare i dati esterni? Come recupero ad esempio le foto o le news dell'artista? Devo renderli metodi dell'ArtistRepository e mapparli come relazioni nell'entità artista esattamente come faccio per gli altri dati? Così facendo non farei che peggiorare il punto sopra.</div><div>Gli articoli o le foto ad esempio dovrebbero essere entità a sè con il loro repository ecc. Come faccio a legare i due?</div><div><br></div><div>Perdonatemi la lunghezza, e grazie in anticipo :)</div><div><br></div><div>Simone</div><div><br></div></div>