[pugMI] Dubbi su architettura / data mapper / repository ecc... HELP! :)

[Matteo Vaccari]

>
>
> 1) PROBLEMI DI PERFORMANCE
>
> 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.
>

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".


>
> 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.
> 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.
> 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.
>

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.



> 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.
>
> Questo mi genera una serie di perplessità:
> - dal punto di vista dell'entità il concetto di cosa è stato idratato o
> meno non ha assolutamente senso
> - l'aggiunta di metodi come withBaseData o withRelations rende il
> repository troppo specifico e difficilmente astraibile in un'interfaccia
> repository generica.
> - questo mi blocca nel caso volessi usare un decorator per aggiungere un
> livello di logging piuttosto che di caching tramite file / redis ecc
> - potrei certo costruire un'interfaccia ad hoc ma sto cercando di capire
> se può essere ripensato il tutto per salvare capra e cavoli
>
> 2) PROBLEMI DI RECUPERO DATI ESTERNI
>
> 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.
>

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.

Matteo
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.grusp.org/pipermail/milano-grusp.org/attachments/20150716/c02bf245/attachment.htm>