App Engine - RequestFactory против сервлетов против других подходов - PullRequest
Новая
       24

App Engine - RequestFactory против сервлетов против других подходов

6 голосов
/ 31 декабря 2011

Наша команда работает над Android-приложением, дополненным App Engine.У нас есть некоторые расхождения во мнениях относительно реализации взаимодействия клиент-сервер.С одной стороны, App Engine предлагает подход RequestFactory, который (как говорят в Google)

provides a solid foundation for automatic batching and caching of requests in the future

и light-weighed

Но мы находим этоподойти немного "неуклюже".С другой стороны, мы можем использовать обычный подход к сервлетам, который мы хорошо знаем и с которым мы чувствуем себя более комфортно.Мы уверены, что хотим легче , быстрее и масштабируемые коммуникации, но в какой пропорции RequestFactory действительно обеспечивает их?Что еще мы можем получить и проиграть от обоих подходов.

[Более того, мы читаем о таких опциях, как GWT-RPC (более старая версия RequestFactory) и RestyGWT.Но мы мало знаем об этих подходах и не уверены, соответствуют ли они нашему случаю.]

Я нашел здесь несколько похожих вопросов без ответа.Так что я полагаю, это может быть полезным обсуждением для многих.

1 Ответ

5 голосов
/ 31 декабря 2011

Несколько замечаний:

  1. RequestFactory не является частью AppEngine (см. здесь ), но является дополнением, представленным последним плагином Android Eclipse.Изначально RequestFactory был создан для GWT.

  2. Преимущество RequestFactory в том, что он бесперебойно работает с GWT и Android.

  3. Недостатком является то, что он не кроссплатформенный, то есть недоступен для iPhone и т. Д.

  4. Непонятно, как версия RequestFactory.Если ваше приложение является большим и развивающимся, вы обязательно должны иметь две или более версии API-интерфейсов RPC, обслуживающих клиентов.Клиенты GWT могут быть легко вынуждены использовать новейший API (= перезагрузка страницы), что не так с Android.AFAIK, нет возможности иметь две конечные точки RequestFactory.С REST вы можете просто иметь несколько URL-адресов для разных версий API.

  5. Смешивание публичных / приватных API.Поскольку не существует нескольких конечных точек RequestFactory, вы не можете легко разделить их на общедоступные (не требуется авторизация) и частные / безопасные (= требуется авторизация).С помощью REST (и GWT-RPC) вы можете просто иметь два сервлета (частный и общедоступный) и устанавливать ограничения безопасности в web.xml (или иметь свой собственный фильтр сервлетов).

  6. RequestFactory не поддерживает java.util.Map.Это сильно ограничивает возможность иметь сущности с динамическими свойствами - для этого есть обходные пути, но они являются IMO ненужным кладжем (например, наличие двух списков, один для ключей, другой для значений).

Решение: Это решение, которое я использую в своих проектах:

  1. Создайте слой службы, который возвращает объекты домена POJO.

  2. Создать уровень RPC, который вызывает уровень обслуживания.У вас может быть несколько технологий RPC, вызывающих один и тот же уровень обслуживания.У меня обычно есть GWT-RPC и REST.

  3. Использование доменных объектов только для POJO иногда невозможно (также из-за JPA / JDO), что вынуждает вас создавать DTO.Поддержка DTO - это боль, и я стараюсь избегать их, если это возможно.Можно использовать объекты домена большую часть времени с некоторыми обходными путями: в AppEngine вы можете получить большую помощь, используя Objectify вместо низкоуровневого / JPA / JDO.Он поддерживает GWT-RPC .С REST я предлагаю вам использовать Джексона, где вы можете делать все виды пользовательских преобразований .

...