Сравнение между GWT и Spring MVC - PullRequest
6 голосов
/ 22 октября 2011

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

Одной из проблем со старой парадигмой для меня является тестируемость уровня Spring MVC. Я обнаружил, что из-за непроверяемых аннотаций в ваше приложение может попасть много ошибок. Эта модель также замедляет циклы разработки, потому что вам нужно перезапустить сервер, чтобы внести изменения в код аннотации / контроллера ... что лично меня очень раздражает.

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

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

Я был бы очень признателен за сравнение этих двух. Пожалуйста, имейте в виду, что у меня нет опыта работы с GWT, но у меня более 10 лет опыта работы с Spring. Спасибо!

Ответы [ 3 ]

4 голосов
/ 22 октября 2011

Я использую GWT уже более года в сложном проекте (200 KLOC для всего проекта), и я рекомендую вам попробовать GWT.

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

Преимущество использования GWT состоит в том, что можно создавать красивые, быстрые и поддерживаемые веб-приложения, не зная очень мало о браузерах или javascript. Вы также можете отлаживать код на стороне клиента с помощью отладчика Java, а в сложных приложениях это огромно.

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

4 голосов
/ 22 октября 2011

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

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

Что касается совместимости с браузерами, то после использования современной библиотеки их будет очень мало.Мой код работает во всех браузерах без особых проблем, включая IE 6. Кроме того, когда я слишком занят, я пишу только сервисы и выполняю часть интерфейса JavaScript, что повышает производительность.

В любом случае, это довольносубъективно, другой человек, свободно владеющий GWT, может иметь мою противоположную точку зрения.В любом случае я отклоню следующие причины:

  • простота отладки .Теперь это не так: очень легко отлаживать JavaScript с помощью FireBug, плюс в JavaScript не будет никакой бизнес-логики, только вызов и отображение сервисов.
  • совместимость с браузерами .Помните, что есть несколько причуд, наиболее распространенным является то, что IE не принимает запятые в списках, что в любом случае не входит в стандарт, но Firefox допускает их.Любая современная библиотека JavaScript позаботится о совместимости для вас.
  • Скорость .Для начала скажу, что JavaScript очень быстрый для любых разумных вычислений в браузере.Что медленнее, так это манипулирование DOM и все, что связано с сетью, например, вызовы AJAX.Ваша страница будет работать правильно, если вы не допустите ошибок проектирования, таких как вставка слишком большого количества вещей или другие проблемы, которые могут возникнуть при добавлении множества элементов непосредственно в DOM, вместо построения структуры и последующего присоединения всего сразу.

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

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

Контроллеры имеют очень мало кода для тестирования, я мог бы просто вызвать их и проверить их в JUnit, но, по крайней мере, на данный момент, мой подход заключается в том, чтобы сделать простой внешний тест через веб-страницу с вызовами jQuery, которыепроверьте их ответ (это не модульный тест, это интеграционный тест, но я чувствую, что для модульного тестирования контроллера очень мало смысла, если он написан правильно).

1 голос
/ 06 мая 2014

Мне потребовалось несколько месяцев, чтобы достаточно хорошо выучить Spring, чтобы создавать довольно простые приложения MVC. У меня ушло около месяца, чтобы освоить GWT. (Возможно, это было проще, потому что я уже три года работал с Android, и он работает аналогично. У него даже есть точно такие же неочевидные решения некоторых из его проблем.) Так что для меня GWT определенно было намного легче изучить, чем Spring.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...