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

[Marco Vito Moscaritolo]

2015-07-17 10:38 GMT+02:00 Gaetano Giunta <giunta.gaetano a gmail.com>:

>  Simone Magnaschi wrote:
>
> 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?
>
> In effetti una 'feature' che mi sembra relativamente semplice da
> implementare ma raramente vedo in pratica e' quella di avere un
> transport-layer flessibile nelle librerie di tipo WS.
>
> A parte il trasporto http si potrebbe prevedere il trasporto in-memory,
> evitando quantomeno il parsing relativo al protocollo http, ma mantenendo
> la possibilita' di mettere in cache le risposte.
>

IMHO il gioco non vale la candela, sopratutto se poi pensi di usare sistemi
di caching HTTP (eg reverse proxy) che migliorano le performance riducendo
di molto la complessità applicativa.


> Volendo puntare al massimo delle performances si potrebbe anche bypassare
> la serializzazione+deserializzazione in json, e ritornare direttamente gli
> oggetti generati (tipicamente con l'introduzione della cache ci sarebbe
> comunque una serializzazione, probabilmente usare igbinary e' l'opzione
> migliore per quella).
> Per evitare problemi di references e memleaks, gli oggetti generati dalla
> tua api dovrebbero essere gia' in partenza di tipo 'struttura' prima del
> loro encoding.
>

Tutto vero, ma credo che sia utile solo in situazioni VERAMENTE ESTREME
(poi magari mi sbaglio :D )


> Rimarrebbero i vantaggi:
> - api WS disponibile con zero sforzo
> - separazione netta tra la tua 'facade' sui database legacy compositi e il
> codice front che consuma i ws
>

Che IMHO è il vero vantaggio, anche a costo di un pò più di complessità e
"meno pulizia" nel codice.

Ciao
       Marco
--
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/27aae25f/attachment.htm>