2011-11-25 9 views
10

sto pensando sulla migrazione mio livello di servizio attuale sulla base di GWT-RPC a qualcos'altro. Si tratta di circa 10 interfacce di servizio con 5 metodi ciascuna, che coinvolgono circa 20 entità di dominio diverse, quindi hai un'idea della quantità di lavoro che richiederebbe di cambiare l'intera cosa, che ovviamente vorrei ridurre al minimo. Sto anche usando Gilead e un Servlet centralizzato basato su Guice per gestire tutte le richieste RPC.RestyGWT vs RequestFactory

Le principali ragioni del cambiamento sono:

  • TypeSerializers stanno consumando la maggior parte grande della dimensione del codice app.
  • serializzazione/deserializzazione sul lato client è SLOW specialmente in modalità dev, che sembra essere un fatto comune con GWT-RPC.
  • Ovviamente desidero minimizzare il carico sul filo, ma non è un requisito duro.

Le opzioni che sto pensando sono:

  • RequestFactory, che viene promosso come una bestia più veloce. Ma temo che sarebbe molto lavoro per sostituire tutti i riferimenti nel codice client degli oggetti dominio alle loro controparti proxy, e anche io sono pigro per costruire effettivamente tutti i proxy.

  • Un approccio JSON/REST completo che utilizza RestyGWT, che sembra che mi consenta di utilizzare ancora gli oggetti dominio, ma temo che finirebbe con una deserializzazione ancora più lenta? Non sono basato su alcun fatto, ma non sono riuscito a trovare alcun tipo di benchmark. È solo un'impressione

Mi piacerebbe davvero ricevere suggerimenti.

Grazie!

+3

Un'altra cosa da pensare è che l'intero approccio JSON/REST consente ad altri clienti di interagire con il server più facilmente. –

+0

Questo è vero, ed è un punto a favore di JSON/REST. Ma per ora mi interessa di più delle prestazioni. Inoltre sto progettando di sviluppare client mobili con GWT anche così, finché non diventerò nativo che è molto lontano in futuro, sto bene con un livello di servizio che funziona solo con GWT. –

+0

Hai considerato l'utilizzo dei tipi di sovrapposizione GWT? Vengono con un costo di deserializzazione molto basso (quasi per definizione). – Hbf

risposta

1

Anche se stiamo lavorando con RequestFactory, sto raccomandando REST. Questi sono i 3 motivi principali per cui:

  1. client e server implementazioni non devono essere dipendenti (se mai intenzione di applicazioni native per un dispositivo non Android di dimenticare requestfactory).
  2. nuovi cambiamenti API pausa requestfactory vecchio codice cliente (questo ha effetti devastanti sulla produzione)
  3. l'ecosistema REST e le comunità sono più grandi ed è più facile per affrontare i problemi nel codice, e consentire altre applicazioni per comunicare con il vostro in il futuro.
Problemi correlati