<div dir="ltr">Scusate, stavo dando per scontato, ma con JSON-API non intendo genericamente API che usano JSON ma <a href="http://jsonapi.org/">http://jsonapi.org/</a> (che è uno standard abbastanza recente).<div><br></div><div>Ciao</div><div>        Marco</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-16 16:58 GMT+02:00 Marco Vito Moscaritolo <span dir="ltr"><<a href="mailto:mavimo@gmail.com" target="_blank">mavimo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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):<div><br></div><div> 1) Definizione di una libreria contenente le entity </div><div> 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</div><div> 3) Creazione di un client che in base alle informazioni richieste chiede i dati al WS.</div><div><br></div><div>Ad occhio sembra un pò tutto overkill, però:</div><div><br></div><div>  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.</div><div><br></div><div>  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 <a href="https://github.com/neomerx/json-api" target="_blank">https://github.com/neomerx/json-api</a> e <a href="https://github.com/neomerx/limoncello" target="_blank">https://github.com/neomerx/limoncello</a> 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)</div><div><br></div><div>  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:</div><div><br></div><div>    $myEntity = $myEntityRepository->getById(123, [</div><div>        'my_entity.author',</div><div>        'mia_entity.comments',</div><div>    ]);</div><div><br></div><div>    foreach ($myEntity->comments as $comment) {</div><div>        var_dump($comment->getTitle());</div><div>    }</div><div><br></div><div>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).</div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Non credo matchi esattamente con il tuo problema, quindi magari è una strutturazione che non è adeguata al tuo problema, però magari si :)</div><div><br></div><div>Ciao</div><div>        Marco</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">2015-07-16 15:03 GMT+02:00 Gaetano Giunta <span dir="ltr"><<a href="mailto:giunta.gaetano@gmail.com" target="_blank">giunta.gaetano@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Per quel che riguarda eZ ti posso solo indirizzare a:<br>
<br>
<a href="http://ezsystems.github.io/slides/" rel="noreferrer" target="_blank">http://ezsystems.github.io/slides/</a><br>
<a href="http://doc.ez.no" rel="noreferrer" target="_blank">http://doc.ez.no</a><span><br>
<br>
Simone Magnaschi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Grazie Gaetano,<br>
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).<br>
Ho provato a dare un'occhiata veloce a <a href="https://github.com/ezsystems/ezpublish-kernel/" rel="noreferrer" target="_blank">https://github.com/ezsystems/ezpublish-kernel/</a> ma come immaginavo a una code base abb. complessa.<br>
</blockquote>
<br></span>
solo un filino... :-D<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
Per caso hai articoli o risorse per poter approfondire quel tipo di approccio?<br>
<br>
Grazie ancora<br>
S.<br>
<br></span>
[...]<br>
</blockquote>
<br>
ciao<div><div><br>
_______________________________________________<br>
Milano mailing list<br>
<a href="mailto:Milano@ml.grusp.org" target="_blank">Milano@ml.grusp.org</a><br>
<a href="http://ml.grusp.org/listinfo.cgi/milano-grusp.org" rel="noreferrer" target="_blank">http://ml.grusp.org/listinfo.cgi/milano-grusp.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Ciao<br>       Marco<br>--<br>web:     <a href="http://mavimo.org" target="_blank">http://mavimo.org</a><br>mob:     <a href="tel:%2B39%20393%209249923" value="+393939249923" target="_blank">+39 393 9249923</a><br>skype:   marco.moscaritolo<br>twitter: @mavimo</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ciao<br>       Marco<br>--<br>web:     <a href="http://mavimo.org" target="_blank">http://mavimo.org</a><br>mob:     +39 393 9249923<br>skype:   marco.moscaritolo<br>twitter: @mavimo</div>
</div>