RestyGWT против RequestFactory

Я думаю о переносе моего текущего уровня обслуживания на основе GWT-RPC на что-то другое. Это около 10 сервисных интерфейсов с 5 методами в каждом и около 20 различных объектов предметной области, так что у вас есть представление об объеме работы, который потребуется, чтобы изменить все это, что, очевидно, я хотел бы минимизировать. Я также использую Gilead и централизованный сервлет на основе Guice для обработки всех запросов RPC.

Основными причинами изменения являются:

  • TypeSerializers потребляют большую часть размера кода приложения.
  • Сериализация/десериализация на стороне клиента выполняется МЕДЛЕННО, особенно в режиме разработки, что, по-видимому, является обычным явлением для GWT-RPC.
  • Очевидно, я хотел бы минимизировать полезную нагрузку на проводе, но это не является жестким требованием.

Варианты, о которых я думаю, следующие:

  • RequestFactory, который продвигается как более быстрый зверь. Но я боюсь, что будет много работы, чтобы заменить все ссылки в клиентском коде объектов домена на их прокси-аналоги, а также мне лень собственно строить все прокси.

  • Полный подход JSON/REST с использованием RestyGWT, который, похоже, позволит мне по-прежнему использовать объекты домена, но я боюсь, что это приведет к еще более медленной десериализации? Я не основываюсь ни на каких фактах, но не смог найти никаких ориентиров. Это просто впечатление.

Я действительно хотел бы получить предложения.

Спасибо!


person Ariel Scarpinelli    schedule 25.11.2011    source источник
comment
Еще одна вещь, о которой следует подумать, это то, что полный подход JSON/REST позволяет другим клиентам более легко взаимодействовать с вашим сервером.   -  person Riley Lark    schedule 26.11.2011
comment
Это правда, и это аргумент в пользу JSON/REST. Но сейчас меня больше волнует производительность. Кроме того, я планирую разрабатывать мобильные клиенты с GWT, поэтому, пока я не перейду на родной язык, что произойдет далеко в будущем, меня устраивает сервисный уровень, который работает только с GWT.   -  person Ariel Scarpinelli    schedule 01.12.2011
comment
Рассматривали ли вы возможность использования типов наложений GWT? Они поставляются с очень низкой стоимостью десериализации (почти по определению).   -  person Hbf    schedule 26.02.2012
comment
@Hbf да, но при этом я должен создавать отдельные объекты модели/домена для моего клиентского кода, а не для моего серверного кода, поскольку они должны расширять JavascriptObject. Одним из пунктов использования RestyGWT будет использование одного и того же объекта для обеих сторон, так как обе базы кода должны поддерживать эти объекты и работать с ними.   -  person Ariel Scarpinelli    schedule 01.03.2012
comment
@triforce: Понятно, в этом есть смысл. – В некоторых проектах я обнаружил, что использую DTO гораздо чаще, чем отправляю настоящие объекты. Чтобы минимизировать усилия по поддержке, я изучил автоматическую генерацию классов DTO и Action/Result во время компиляции. Это сработало для меня довольно хорошо: статическая типизация для отлова ошибок, мне не нужно было писать шаблонный код. Вот такой подход: code.google.com/p/gwt- platform/wiki/, но я обнаружил, что он недостаточно гибкий, и начал писать свой собственный.   -  person Hbf    schedule 02.03.2012
comment
Если вы ищете производительность и рассматриваете возможность использования RestyGWT, вам определенно следует подумать о создании некоторых конкретных DTO. Потому что вы не хотите отправлять всю свою модель своему клиенту. В зависимости от вашего варианта использования вам может понадобиться только половина информации, содержащейся в вашей модели, поэтому отправка всего объекта будет неэффективной. Это ускорит сериализацию/десериализацию. Кроме того, с точки зрения многоуровневого приложения хорошо различать вашу модель и то, что вы предоставляете своим клиентам.   -  person Ronan Quillevere    schedule 04.12.2013


Ответы (1)


Хотя сейчас мы работаем с RequestFactory, я рекомендую REST. Вот 3 основные причины:

  1. реализации клиента и сервера не должны быть зависимыми (если вы когда-нибудь планируете собственные приложения для устройства, отличного от Android, забудьте о requestfactory).
  2. новые изменения API в requestfactory ломают старый клиентский код (это имеет разрушительные последствия для производства)
  3. Экосистема REST и сообщества стали больше, проще решать проблемы в коде и позволить другим приложениям взаимодействовать с вашими в будущем.
person shukshuk    schedule 24.09.2013