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

[Simone Magnaschi]

Grazie Matteo per le tue considerazioni, in linea alcuni commenti.


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

La costruzione di query adhoc è quello che vorrei evitare. Sto cercando un
compromesso tra modularità e standardizzazione.


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


>
>
>> 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/20150717/67b27f94/attachment-0001.htm>