Spring + GWT или Spring против GWT

Фон

Я занимаюсь разработкой веб-приложения с использованием GWT, Java и EclipseLink. Каждый из этих вариантов - это выбор, который я сделал для реализации этой программы. GWT - единственный выбор, где нет четкого понимания того, что именно сравнивается с чем-то вроде Spring. Прямо сейчас я использую виджеты GWT для реализации клиента и GWT RequestFactory для реализации взаимодействия между сервером и клиентом объектов из EclipseLink.

представления

Итак, я рассматриваю GWT как в первую очередь библиотеку виджетов с простой структурой для связи между сервером и клиентом. Это то же самое, что я рассматриваю Spring, библиотеку виджетов с гораздо более сложной структурой для управления связью между сервером и клиентом - с возможностью того, что она не реализует AJAX так же удобно, как GWT.

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

Вопросы

Есть ли неправильное представление о представлениях GWT и Spring? Если да, то некоторые краткие руководящие указания об этом будут высоко оценены!
Что будет встречной частью виджетов GWT в Spring Framework?
Что было бы встречной частью GWT RequestFactory в Spring Framework?

Ответ 1

Это действительно зависит от того, как вы планируете использовать GWT в своем приложении.

GWT лучше всего использовать для веб-приложений с одной главной страницей.
Это означает, что вся синхронизация потока и бизнес-логика выполняются на стороне клиента с помощью GWT.
Здесь GWT действительно сияет (см. здесь для получения дополнительной информации).

Однако, если вы поедете по этой дороге, вы получите в основном два разных приложения. У вас будет интерфейс, разработанный с GWT и бэкэнд с использованием Spring, например. Ваш сервер (Spring или все, что вы используете) будет действовать только как "хранилище данных", предоставляя вам данные, которые вы собираетесь отображать в своем интерфейсе GWT. Таким образом, вы, вероятно, не используете какую-либо функциональность Spring MVC's.

Конечно, вы также можете использовать Spring MVC и использовать GWT только для добавления функциональности web 2.0ish на ваш сайт, но для этого варианта использования я бы рекомендовал скорее использовать jQuery, Closure или другие фреймворки javascript.

На ваши вопросы:

Есть ли неправильное представление о представлениях GWT и Spring? Если так, некоторые краткие руководящие указания по этому поводу будут высоко оценены!

Если вы используете GWT, поскольку он предназначен (веб-приложения с одной главной страницей), вы не будете использовать часть MVC Spring. Вы все равно можете использовать авторизацию, аутентификацию, ORM и многие другие компоненты структуры Spring, однако GWT обрабатывает все представления.
Spring действует более или менее только как хранилище данных для вашего внешнего приложения GWT. Это похоже на наличие двух разных и отдельных приложений, подключенных по протоколу связи (RequestFactory, REST, RPC и т.д.).

Какова будет контр-часть виджетам GWT в Spring Framework?

В структуре Spring нет реальной встречной части для виджетов GWT (возможно, для некоторых расширяет JSF). Spring - все о стороне сервера, поэтому все его виды создаются на стороне сервера. В то время как GWT касается клиентской стороны.

Что было бы встречной частью GWT RequestFactory в SpringFramework

RequestFactory - это протокол связи между вашим внешним приложением (GWT) и вашим backend-приложением ( Spring). Когда вы используете Spring MVC, вам не нужен какой-либо коммуникационный протокол, поскольку представления генерируются на стороне сервера, где у вас уже есть данные.

Ответ 2

GWT - это не библиотека виджетов, а целая структура для создания полных веб-приложений, которые работают в клиенте, а не на стороне сервера. Основное отличие состоит в том, что spring (шаблон MVC) ориентирован на сервер, поэтому он подключается к ddbb, выполняет бизнес-логику и создает представление для отправки клиенту, поскольку GWT (шаблон MVP) запускает ведущий в браузере, который создает представление, и он просто подключается к серверу для получения результатов или объектов (удаленных методов).

Сказано, что в зависимости от вашего приложения GWT вам может понадобиться более или менее логика на стороне сервера и другие элементы, такие как ddbb, spring и т.д.

Решение о том, когда выбрать GWT или любую другую структуру, зависит от того, нужно ли вам использовать богатое (настольное приложение) приложение, работающее в браузере.

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

Лучший способ изучить эту комбинацию - изучить небольшой проект, созданный с помощью Spring-roo. Он может создать целый проект со всем набором для maven, spring, gwt, mvp и rf. Просто установите roo 1.2.2 и запустите этот набор команд в консоли roo:

project --topLevelPackage com.project.contacts
persistence setup --provider ECLIPSELINK --database HYPERSONIC_PERSISTENT
database properties set --key database.url --value jdbc:hsqldb:/var/tmp/contacts.db
entity jpa --class com.project.contacts.domain.Contact --testAutomatically
field string name --notNull --sizeMin 1 --sizeMax 30 --class ~.domain.Contact
field string surname --notNull --sizeMin 1 --sizeMax 30 --class ~.domain.Contact
field string phone --notNull --sizeMin 1 --sizeMax 15 --class ~.domain.Contact
web gwt setup
web gwt all --proxyPackage ~.client.proxy --requestPackage ~.client.request
quit

Затем выполните

mvn gwt:run

Основная проблема, которую я вижу с помощью roo, заключается в том, что она использует "aspectj" для обновления управляемых классов при изменении модели, но вы можете удалить зависимостей roo и файлы aspectj с помощью eclipse после того, как ваш проект был настроен.

Ответ 3

Отметьте Objectify для вашего бэкэнд. Путь проще.