#java #spring #gwt #spring-mvc
#java #spring #gwt #spring-mvc
Вопрос:
Мне было интересно, может ли кто-нибудь, имеющий опыт работы с обеими технологиями, дать объективное сравнение между ними, предполагая, что вы создаете сложное веб-приложение, которое было бы очень богатым как на сервере, так и в браузере.
Для меня одной из проблем, связанных со старой парадигмой, является возможность тестирования уровня Spring MVC. Я обнаружил, что в ваше приложение может проникнуть множество ошибок из-за непроверяемых аннотаций. Эта модель также замедляет циклы разработки, потому что вам нужно перезапустить сервер, чтобы внести изменения в код аннотаций / контроллера … что лично меня очень раздражает.
Я также не хочу иметь дело со сложностью javascript. Работа с приложением и его тестирование на Java кажутся мне привлекательными. Я действительно не хочу осваивать другой язык и изучать все его причуды, странные дизайнерские решения, особенности и полную историю несовместимости браузеров.
Итак, для сложного приложения будет ли GWT предлагать превосходный подход? Существуют ли какие-либо серьезные ограничения для этого подхода по сравнению с Spring MVC, который, вероятно, был бы более гибким, хотя с ним было бы сложнее работать? Есть ли какие-либо ошибки и препятствия, которые являются общими для создания сложных приложений?
Я был бы очень признателен за сравнение между ними. Пожалуйста, имейте в виду, что у меня нет опыта работы с GWT, но около 10 лет опыта работы с Spring. Спасибо!
Комментарии:
1. При рассмотрении GWT проверьте, приемлема ли для вас производительность.
Ответ №1:
Правда в том, что у 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. Я также тестирую свои контроллеры, поэтому, возможно, мне следовало быть более понятным. Невозможно выполнить модульное тестирование аннотаций ваших контроллеров в модульном тестировании. Например, если вы забудете добавить @PathVariable к параметру метода, ваш модульный тест все равно пройдет. Кроме того, если вы неправильно назвали или неправильно написали сопоставление запроса, вам необходимо перезапустить сервер. Очевидно, что раздражение от этого будет варьироваться от человека к человеку, но я хочу иметь возможность протестировать как можно больше этого материала, прежде чем даже запускать tomcat для тестирования представлений. Кроме того, Spring Container / Hibernate очень медленно запускается для больших приложений.
2. Я получаю ваше дополнительное объяснение. Однако GWT не является заменой Spring, поэтому проблемы, которые вы описали, все еще будут существовать в настройке Spring GWT. Что касается остальной части моего ответа, это, конечно, мое мнение.
3. Если это так, то я думаю, что я в значительной степени закончил с написанием веб-приложений. Мне просто не нравится javascript. Базовый API, предлагаемый во всех браузерах, довольно плох, и я полагаюсь на 4-6 основных библиотек (выше jquery и плагинов jquery) только для получения базового API программирования. Существует так много стилей кодирования javascript, соглашений об именах и т. Д., Которые, я думаю, являются слишком большой когнитивной нагрузкой для тех, кто не использовал его годами. На самом деле это просто неудачно. Кроме того, я пробовал различные методы модульного тестирования, и ни один из них не удовлетворил меня. Это просто неудачно.
4. Одна вещь, которая сделала бы Spring MVC более приятным, — это то, что IDE или дизайн не позволяют вам даже запускать tomcat, если аннотации неверны, например, ошибка компиляции или что-то в этом роде. Программирование в браузере или на Javascript сложнее, чем должно быть. Это намного сложнее, чем просто вызвать нижнюю часть, это уж точно. Лучшей платформой модульного тестирования была JsTestDriver, но она была глючной и даже сообщала о 0 сбоях, когда на самом деле тесты иногда терпели неудачу. В других случаях он просто блокировался и заставлял вас повторно открывать ide и браузеры: (
5. @egervari: Не так сложно объединить ваши контроллеры вместе с аннотациями: просто загрузите контекст Spring и отправьте макет HTTP-запроса.
Ответ №2:
Я использую GWT уже более года в сложном проекте (200 KLOC для всего проекта), и я рекомендую вам попробовать GWT.
На мой взгляд, GWT довольно прост в освоении, есть действительно хорошие учебные пособия о том, как следует использовать эту технологию.
Преимущество использования GWT заключается в том, что можно создавать красивые, быстрые и поддерживаемые веб-приложения, не зная очень мало о браузерах или javascript. Вы также можете отлаживать код на стороне клиента с помощью Java-отладчика, и в сложных приложениях это имеет огромное значение.
Хотя GWT предлагает возможность правильного модульного тестирования кода на стороне клиента, это требует хорошего понимания парадигмы MVP GWT и тщательного планирования. Если вы испортите свой код (что не так сложно, потому что GWT дает вам полную свободу), то в конечном итоге вы потеряете эту функцию, но это ваша вина, а не GWT.
Ответ №3:
Мне потребовалось пару месяцев, чтобы изучить Spring достаточно хорошо, чтобы создавать довольно базовые приложения MVC. Мне потребовалось около месяца, чтобы освоить GWT. (Возможно, это было проще, потому что я уже три года работал с Android, и он работает аналогично. Он даже имеет точно такие же неочевидные решения некоторых своих проблем.) Так что для меня GWT определенно было намного проще в освоении, чем Spring.