<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>Scrivi query ad hoc per ottenere tutte le righe che ti servono in una maniera sufficientemente veloce.  Poi copi i dati dalle righe all'oggetto "gruppo".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>I dati che recuperi per mostrarli in una pagina HTML non devono necessariamente essere gli stessi che recuperi per effettuare una modifica.  Se per esempio vuoi aggiungere un alias al batterista degli Oasis, nel punto dove ricevi quel comando e' sufficiente recuperare solo lo specifico artista, non tutto il gruppo.  In alcuni casi ti potrebbe convenire avere dei metodi ad hoc nell'ArtistRepository tipo addAlias().  Si' non e' OO ma in alcuni casi andare a perlustrare tutto l'oggetto artista e vedere che cosa devo salvare e che cosa no puo' essere complicato.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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 style="white-space:pre-wrap">        </span>- dal punto di vista dell'entità il concetto di cosa è stato idratato o meno non ha assolutamente senso</div><div><span style="white-space:pre-wrap">    </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 style="white-space:pre-wrap">                </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 style="white-space:pre-wrap">            </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></blockquote><div><br></div><div>Distingui quello che ti serve per il display sulla pagina da quello che ti serve per le operazioni sul dominio.  I dati che usi nel secondo caso di solito sono molto meno di quelli che ti servono nel primo.</div><div><br></div><div>Matteo</div></div></div></div>