<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Grazie Matteo per le tue considerazioni, in linea alcuni commenti.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></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></span><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><span><div> </div></span></div></div></div></blockquote><div><br></div><div>La costruzione di query adhoc è quello che vorrei evitare. Sto cercando un compromesso tra modularità e standardizzazione.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></span><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><span><div><br></div></span></div></div></div></blockquote><div><br></div><div>Qui mi sono spiegato male, sorry. Il batterista degli Oasis per me è solo un artista come un altro. Ok ha una relazione con gli Oasis (ma quella relazione è espressa solo come id in un sotto oggetto relationship). Non avrò mai un grafo di artista contenente tutti i sotto oggetti artista collegati ad esso. Quindi se volessi operare su di lui opererei lavorando direttamente su quell'artista. Il problema è che il mio metodo persist al momento va a fare il salvataggio di tutto l'oggetto artista così come gli viene passato mappandolo su tutte le tabelle. Quindi se per errore o scelta non ho recuperato i meta e questi non sono presenti all'atto del salvataggio questi andranno persi perchè il comando ritiene di doverli cancellare. Mi sembra di capire che tu consigli di avere metodi specifici tipo persistAlias persistMeta ecc.</div><div>Forse in questo caso la mia ipotesi del withBaseData withMeta potrebbe essere applicata anche al metodo persist in modo da istruire il repository di salvare solo quelle parti. Non so sono confuso :DD</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></span><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><span><font color="#888888"><div><br></div><div>Matteo</div></font></span></div></div></div>
</blockquote></div><br></div></div>