QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

Какой Java Web фреймворк выбрать?

Коллеги, так получилось что я в основном занимаюсь программированием бэк-енда и тема разработки GUI прошла мимо меня
а учитывая что для Java существует наверное более 20 веб фреймворков , в голове путаница полная.

пишу я такое приложение — это будет Rich Web UI с отрисовкой графики на клиенте (работа с картами ). пока что это сделано в качестве прототипа только на HTML(5) и Javascript.
будет так же сервер, предположительно в виде набора REST API на Джаве. пока еще не решил на каком фреймворке. сервер будет поставлять по запросу различную ГИС-информацию в формате JSON или XML (например — дорожные пробки, или банкоматы ) которую клиент сам будет накладывать на карту .

c точки зрения дизайна веб-клиент — одностраничное приложение, больше похожее на обычный десктопный UI. то есть нужно заюзать что-то вроде AJAX там где нужно, чтоб не было никаких постбеков и перезагрузок страницы, чтоб с точки зрения пользователя выглядело как будто он работает в Google Earth

в современных веб фреймворках я чайник, последний раз хтмл ковырял лет 7 назад, когда на ASP.NET немного програмил

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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

спринг будет лучшим выбором

Не «спринг», а Spring. Точнее, Spring MVC.

Вообще слишком обобщенный вопрос, к этому описанию допустимо ещё слишком много возможных требований. Конкретизируйте что будет происходить на сервере. А то в данном случаи подойдёт почти любой фреймворк, коих туча, все они подпадают под описание.
Тут предложили Play Framework и Spring Framework, моё видение таково:
Play Framework это: Scala (хотя можно и на Java), свой шаблонный язык, асинхронность с коробки Future/Promise, Google Guice (на stable версии без инициализации по аннотациям, пока, нужно вручную прописывать какие бины создать), Akka (подробнее можно познакомиться с акторами), EBean ORM (после Spring Data выглядит не очень читаемым), SBT (есть баги с Gradle или Maven ).
Spring это: Spring Data JPA, Spring IoC (огромное количество плюшек), Spring MVC, свой шаблонный язык, работает с Gradle и Maven без проблем.

Ещё можете посмотреть дополнительные библиотеки для ускорения написания кода, как lombok.

сервер поставляет карты в виде картинок от различных провайдеров (google, navteq, mapquest) . они должны где-то кешироваться чтобы избежать повторных запросов к провайдеру. а также метаданные и прочую неграфическую информацию в виде структурированного текста (JSON или XML). пока что для прототипирования сделал по быстрому на базе Jersey.

По запросам, прям Vaadin
Танунах?!
Ваадин и РЕСТ? 2-3 года назад, в нем небыло особой поддержки РЕСТа ни как сервера, ни как клиента.
Танунах?!

Такая же первая мысль.

Я что-то упустил, или vaadin, это решение из коробки предоставляющее сразу ui и серверный фреймворк. Если его использовать, то будешь очень сильно завязан на его ui. В свое время пользовался его родителем — GWT. Вешь конечно неплохая, но область, в которой раскрываются все его преимущества — слишком узкая.

будет так же сервер, предположительно в виде набора REST API на Джаве. пока еще не решил на каком фреймворке.
Если в такой формулировке, то я бы брал что-то JAX-RS-реализующее, тот же jersey.java.net довольно хорош. Решение в стиле «я не хочу ничего решать» — dropwizard.io (использует jersey). Это мои предпочтения.
www.playframework.com — «модно, стильно, молодежно», позволяет использовать скалу. REST на нем делать можно, но как по мне маловато возможностей.
projects.spring.io/spring-boot — «я не хочу ничего решать» для рабов спринга. Если так чтобы совсем ничего не решать, то jhipster.github.io
.
В любом случае выбор больше зависит от команды, от навыков людей в команде.
.
c точки зрения дизайна веб-клиент — одностраничное приложение, больше похожее на обычный десктопный UI.
Клиент лучше делать не зависимый от сервера в плане технологий. По вашему описанию можно посмотреть на www.sencha.com , но выбор клиента не должен иметь сильно (или вообще какую-то связь) с выбором серверного фреймворка.

насколько я понял Jersey и DropWizard это почти то же самое — то есть внутри последний использует первый, +дополнительные сервисы. а RestEasy как в сравнении с Jersey?

а RestEasy как в сравнении с Jersey?
В плане АПИ оба — реализации JAX-RS, то есть разницу вы вряд ли заметите.
RestEasy — это продукт JBoss, поэтому в контексте всякой политики, возможно, он будет более активно развиваться, но пока Jersey — это reference implementation (то есть «самый правильный путь»).

jersey на stackoverflow в 4 раза популярнее, что означает что под него больше всякой ерунды написали, и грабли опробовали.

Подписаться на комментарии