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

Gio 16 Lug 2015 22:19:09 PDT

Marco grazie, non so se calza con la mia situazione attuale ma mi sembra un
ottimo spunto di riflessione.
Una domanda hai server differenti per i WS e i "client" di questo WS o è la
stessa macchina? Quanto pesa il networking per tutte le chiamate al WS in
termini di performance?
S.

Il giorno 16 luglio 2015 16:58, Marco Vito Moscaritolo <mavimo a gmail.com>
ha scritto:

> Premetto che sto affrontando un problema "simile" (banca dati legacy
> intoccabile con struttura abbastanza complicata) io ho affrontato il
> problema nel seguente modo (premetto che non sono scuro della strada, ma
> -per ora- mi sta dando soddisfazioni):
>
>  1) Definizione di una libreria contenente le entity
>  2) Creazione di un WS che tramite json-api implementa dei WS che espone
> le entity, questo è quello che in realtà si relazione con i DBs
>  3) Creazione di un client che in base alle informazioni richieste chiede
> i dati al WS.
>
> Ad occhio sembra un pò tutto overkill, però:
>
>   1) Nel mio caso definire dei model era abbastanza un delirio (non si sa
> bene quale entity esistevano, con che struttura, che relazioni, .. )
> considerate che si tratta di una base dati di dati con strutture definite
> nella seconda metà del 1800, evolutesi poi nel tempo in cui sono state
> mergiate altre basi dati, avere un elemento esterno ha reso facile capire
> quale erano le strutture realmente esistenti e come queste erano legate.
>
>   2) Usando dei WS posso alterare la struttura della base dati / modo in
> cui interagire senza intaccare il lato applicativo (che poi nel mio caso
> sono più di uno). I WS sono scritti in silex (scelta discutibile, lo so, ma
> per ora mi basta :D ) usando https://github.com/neomerx/json-api e
> https://github.com/neomerx/limoncello con delle integrazioni per silex.
> La cosa MOLTO BELLA di json-api è che puoi definire in maniera sistematica
> nel WS come devono essere idratate le entity richieste in base ai parametri
> passati; nelle ultime versioni delle librerie che ho indicato (a memoria
> >0.5.1) puoi fare lazy loading delle entity relazionate abbastanza
> banalmente. Il layer di interazione è definito da EntityRepostory (uno per
> ogni entity) che si appoggiano a doctrine DBAL (ma potrebbe essere
> tranquillamente direttamente PDO). Questo mi ha permesso di scorporare il
> problema di relazione delle entity dalla loro persistenza in maniera
> abbastanza semplice. Un WS in mezzo inoltre obbliga a definire come
> interagire con le entity. Usando un WS posso applicare caching a livello
> HTTP abbastanza facilmente; la base dati ha > 10^6 oggetti e un tasso di
> richiesta abbastanza alto, quindi DEVO prevedere caching, soprattutto
> perché il tasso di letture è estremamente maggiore alle scritture (di
> diversi ordini di grandezza)
>
>   3) Questa è la parte che mi convince meno, ma in sintesi quando chiedo
> un entity spiego che relazioni voglio fargli caricare in base a quello che
> uso, in questo modo so che entity ho e cosa posso usare, ma al tempo stesso
> ho chiamate del genere:
>
>     $myEntity = $myEntityRepository->getById(123, [
>         'my_entity.author',
>         'mia_entity.comments',
>     ]);
>
>     foreach ($myEntity->comments as $comment) {
>         var_dump($comment->getTitle());
>     }
>
> che come potete ben notare fanno si che possa avere entity inconsistenti
> (che è male) ma per ora è un problema che sto sopportando abbastanza
> facilmente (alla fine i controller dei client fanno poche chiamate e
> ottengo un numero limitato di oggetti che devo mostrare/gestire).
> Per la parte di persistenza quando persisto la entity NON vado a
> persistere le informazioni figlie con un unica chiamata ma eventualmente
> con chiamate a cascata.
>
> NB: questo è legato al mio use case dove le entity sono solo in GET,
> pochissime (100k al mese) PUT e POST oltre a nessuna DELETE (tutti i dati
> sono storicizzati e non cancellabili).
>
> Non credo matchi esattamente con il tuo problema, quindi magari è una
> strutturazione che non è adeguata al tuo problema, però magari si :)
>
> Ciao
>         Marco
>
>
> 2015-07-16 15:03 GMT+02:00 Gaetano Giunta <giunta.gaetano a gmail.com>:
>
>> Per quel che riguarda eZ ti posso solo indirizzare a:
>>
>> http://ezsystems.github.io/slides/
>> http://doc.ez.no
>>
>> Simone Magnaschi wrote:
>>
>>> Grazie Gaetano,
>>> l'approccio sembra molto interessante e sembrerebbe fare al caso mio
>>> dato che parte dei dati li abbiamo su servizi esterni (quindi api e no db).
>>> Ho provato a dare un'occhiata veloce a
>>> https://github.com/ezsystems/ezpublish-kernel/ ma come immaginavo a una
>>> code base abb. complessa.
>>>
>>
>> solo un filino... :-D
>>
>>  Per caso hai articoli o risorse per poter approfondire quel tipo di
>>> approccio?
>>>
>>> Grazie ancora
>>> S.
>>>
>>> [...]
>>>
>>
>> ciao
>>
>> _______________________________________________
>> Milano mailing list
>> Milano a ml.grusp.org
>> http://ml.grusp.org/listinfo.cgi/milano-grusp.org
>>
>
>
>
> --
> Ciao
>        Marco
> --
> web:     http://mavimo.org
> mob:     +39 393 9249923
> skype:   marco.moscaritolo
> twitter: @mavimo
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.grusp.org/pipermail/milano-grusp.org/attachments/20150717/e6727066/attachment.htm>