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

Наша команда работает над приложением для 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. Но мы мало знаем об этих подходах и не уверены, подходят ли они для нашего случая.]

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


android google-app-engine servlets requestfactory
person leonprou    schedule 31.12.2011    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Несколько заметок:

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

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

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

  4. Непонятно, как установить версию RequestFactory. Если ваше приложение большое и развивается, у вас обязательно будет две или более версий RPC API, обслуживающих клиентов. Клиентов GWT можно легко заставить использовать новейший API (= перезагрузка страницы), но не Android. Насколько я знаю, нет возможности иметь две конечные точки 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 я предлагаю вам использовать Jackson, где вы можете выполнять все виды пользовательских преобразований.

person Peter Knego    schedule 31.12.2011
comment
Спасибо за такой полный и информативный ответ, я думаю, что некоторые из ваших решений мы возьмем на вооружение. - person leonprou; 02.01.2012