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

[Marco Vito Moscaritolo]

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/20150716/9b885520/attachment.htm>