Выбор Java Web Framework сейчас? [закрыто]


149

мы находимся на этапе планирования перехода большого веб-сайта, который построен на специально разработанной инфраструктуре mvc, на веб-инфраструктуру на основе Java, которая обеспечивает встроенную поддержку ajax, мультимедийного содержимого, гибридов, макетов на основе шаблонов, проверки, максимального количества HTML / разделение кода Java. Grails выглядел как хороший выбор, однако мы не хотим использовать язык сценариев. Мы хотим продолжать использовать Java. Основанный на шаблонах макет является основной задачей, поскольку мы намереваемся использовать это веб-приложение с несколькими веб-сайтами со схожей функциональностью, но радикально отличающимся внешним видом.

Является ли решение на основе портала хорошим решением этой проблемы?

Любое понимание использования Spring Roo или Play будет очень полезным.

Я нашел подобные сообщения, как это , но это больше года. Вещи, безусловно, изменились за это время!

РЕДАКТИРОВАТЬ 1: Спасибо за отличные ответы! Этот сайт становится лучшим источником информации для программистов. Однако я ожидал больше информации об использовании дуэта portal-cms. Джахия выглядит товаром. Что-нибудь подобное?


1
«Мы не хотим использовать язык сценариев», это позор, почему, если я могу спросить? если вам нравится платформа Play, вы должны попробовать JRuby с Rails. Это не простая Java, но очень просто вызывать Java-классы из JRuby.
Люк

2
Grails (то есть Groovy) очень хорошо играет с Java, не нужно бояться.
Эрих Кицмюллер

4
@hbagchi: просто любопытно; 4 месяца спустя, с какими основами вы пошли? Доволен этим?
Джоник

1
разве это не вопрос сообщества вики?
Mickthompson

11
«Но ему больше года. За это время все, безусловно, изменилось!» ... О да, не дай Бог, чтобы вы использовали технологию, которой более 12 месяцев! Серебряная пуля наверняка была изобретена ... :-)
ObiWanKenobi

Ответы:


146

Является ли решение на основе портала хорошим решением этой проблемы?

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

Любое понимание использования Spring Roo или Play будет очень полезным.

О Spring Roo я читал предыдущие ответы, такие как Spring roo Vs (Wicket и Spring) и другие вещи через Интернет, но я все еще не убежден (возможно, я не понимаю), я не уверен в его зрелости и, что более важно, мне действительно интересно, что SpringSource делает с Grails и Roo (нет, Grails vs Roo - почему SpringSource продвигает две очень похожие технологии? не убеждает меня, что они оба выживут).

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

Я нашел похожие посты (...). Вещи, безусловно, изменились за это время!

Да и нет :) Но давайте войдем в ад фреймворков презентаций: нет однозначного ответа на ваш вопрос (как год назад), там дюжина фреймворков и нет явного победителя. Просто процитировать несколько:

  • JSF: Множество скептиков по поводу этого компонента, основанного на фреймворке, включая меня, поэтому я не лучший, чтобы говорить об этом, но ...
  • JSF 2 (+ CDI / Weld): скептики JSF поощряются ( Гэвин Кинг ) "взглянуть второй раз". Действительно, я думаю, что JSF 2 - большое улучшение, особенно с CDI, но ... оно все еще довольно новое (понимаете, ему не хватает обратной связи). Если вы хотите использовать Java EE 6, проверьте это.
  • Wicket: еще один компонент на основе фреймворка, которому уделяется все больше внимания. Я слышал в основном о хорошем: проще, чем JSF, хороший дизайн, высокую тестируемость, дружелюбный HTML-дизайнер и т. Д. Вам может понравиться.
  • Гобелен: Просто не надо (см. Почему вы перестали использовать Гобелен? )
  • Struts 2, Spring MVC, Stripes: рамки на основе действий. Все прилично и покроет ваши потребности (лично мне нравятся Stripes и его соглашение о подходе к конфигурации, см. Stripes vs. Struts2, чтобы получить представление об этом).
  • GWT, Flex, Grails: Возможно, это не то, что вы ищете. Я не могу говорить о (последних версиях) Flex и GWT, но я знаю, что у Grails есть несколько поклонников .

На самом деле, я бы посоветовал взглянуть на презентации Мэтта Райбла , он действительно проделал огромную работу, сравнивая веб-фреймворки, показывая их сильные и слабые стороны, собирая факты и цифры, показывая тенденции ... Я рекомендую:

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


Хорошую работу я снял :). +1
Адель Ансари

Недавний выстрел Мэтта из веб-сайта Java был ужасен. Если я помню, у стоек было практически то же самое, гораздо более богатое и мощное ПО. Никто не мог бы рассматривать что-то такое же простое, как распорки, достойные оценки, которая всего лишь на несколько пунктов отстает от GWT или Wicket.
мП

3
Да, я понимаю, что многим людям не нравилась моя «матрица» или моя логика для ее рейтингов. В конце концов, я надеялся сделать с этой матрицей простое выделение метода выбора веб-фреймворка. Вы можете прочитать о логике моих рейтингов в следующем сообщении в блоге: raibledesigns.com/rd/entry/how_i_calculated_ratings_for
Matt Raible

Презентация Мэтта Рейбла о сравнении JSF, Spring MVC, Stripes, Struts 2, Tapestry и Wicket действительно довольно старая ...
Nerrve

1
@iberck, я недавно экспериментировал с AngularJS. Честно говоря, я верю, что это будет большинство, если не ВСЕ текущие веб-фреймворки, без преувеличения. Это просто JS-инфраструктура для клиентской стороны, тогда вы можете легко и «эффективно» получать данные с сервера с помощью REST. Попробуйте, это потрясет
Мухаммед Гелбана

41

Я использовал Spring 3 и Jquery некоторое время, но услышал о Play и попробовал. Мне очень нравится, Play отлично подходит для чего-то вроде PHP и мощных сред Java, таких как Spring.

Что мне больше всего нравится в игре:

  • Очень легко получить игровое приложение с нуля, вам нужно продвинуться далеко вперед с кодированием и настройкой, чтобы вывести простое простое приложение на экран с помощью Spring (хотя Spring 3 сделал это намного проще).
  • Spring Security - это круто, но за счет сложности. Модуль безопасности Play очень прост и покрывает потребности примерно 90% приложений.
  • Вы можете внести изменения в код и нажать кнопку «Обновить» в браузере, чтобы увидеть это изменение, как в PHP, вместо того, чтобы выполнять всю процедуру повторного развертывания с помощью фреймворков на основе сервлетов.
  • Сообщения об ошибках отображаются красиво и не так загадочно большую часть времени. Играть все еще нужно работать над их обработкой ошибок
  • Есть механизм плагинов для Play, который довольно прост.
  • Постоянство объектов выполняется очень хорошо в том смысле, что база данных в памяти и JPA поставляются с платформой, поэтому нет никакой конфигурации инструментов сохранения внешних объектов. Переход от базы данных в памяти к реальной СУБД - это изменение в одну строку в файле конфигурации.
  • Настройка MVC выполнена очень хорошо. Класс Model, который вы расширяете для создания своих доменных объектов, интегрируется с менеджером сущностей JPA. Они не просто POJO.
  • Отображение URL на контроллеры является простым и гибким и все в одном файле «маршрутов».
  • Всякий раз, когда вы создаете проект, Play обрабатывает все зависимости jar, а Play имеет утилиту для затмения (или любой другой IDE), которая вам нравится, чтобы он импортировался прямо в вашу любимую IDE.

Вещи которые мне не нравятся в Play

  • Документация еще не до конца, все еще существует множество недокументированных функций.
  • Каркас - это сервер, поэтому вы должны выделить порт для каждого приложения. Я думаю, что кто-то работает над плагином виртуального хоста, но я еще не видел его в действии.
  • Он молод, проект потрясающий, а технологии потрясающие, но для этого действительно нужно больше разработчиков. Я хотел бы посвятить некоторое время этому, посмотрим.

17

Лучший выбор для меня - калитка . Четкое разделение разметки и кода Java. Очень легко писать и использовать компоненты. Простой в использовании Ajax, тестируемость. Вы можете отлаживать прямо на ваших страницах / компонентах и ​​не получать загадочные сообщения об ошибках из вашей реализации JSF;)

Также есть хорошее сравнение калитки <-> JSF с точки зрения производительности


4
+1 Не говоря уже о чистой ООП-ориентации с наследованием, полиморфизмом и композицией. Также XML-файлы конфигурации бесплатны!
Хави Лопес

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

13

Три основных варианта для меня (в алфавитном порядке):

Oни:

  • иметь хорошую поддержку AJAX
  • позволяют создавать реальные веб-сайты, а не приложения (например, GWT)
  • стабильный, хорошо документированный, широко используемый
  • MVC
  • чистая ява
  • простая интеграция с Spring в качестве промежуточного программного обеспечения

17
Я понятия не имею, как можно утверждать, что JSF можно использовать для «создания реальных веб-сайтов». Любая структура, которая вызывает использование POST, немедленно проигрывает в этом отношении.
Стефан Тилков

3
Я разработал «реальные веб-сайты» с JSF, и я использовал их без каких-либо проблем. Кроме того, использование POST является обязательным только тогда, когда вы что-то публикуете. Вы всегда можете использовать простую навигацию GET. Теоретически, неправильно использовать GET, если вы модифицируете ресурс, не так ли?
Божо

Кроме того, вам придется понизить Паскаль, а также за предложение JSF;)
Божо

3
Без обид, но это звучит как список «вещей», которые вы видели много лет назад, поэтому я просто удивлен, увидев это. По моему опыту, большинство с тех пор перешли от тех ошибок. Я полагаю, если вы уже являетесь экспертом в этом, они были бы отличным выбором, но я бы заинтересовался программистами O & M, которые должны вступить во владение после того, как эксперты покинут проект. Никто действительно не изучает этот материал больше IMO.
Маниус

1
Эта строка комментариев действительно немного смешная. JSF, конечно, вполне может быть использован для веб-сайтов, и он имеет первоклассную поддержку как GET, так и POST. Используйте то, что наиболее подходит для конкретной ситуации. Действительно, как указывает Божо, если он изменяет ресурс, не используйте GET, в противном случае не стесняйтесь делать это.
Арджан Тиймс


10

В отличие от других ответов, я хотел бы выделить недостатки (IMHO) популярных веб-фреймворков:

JSF2 - выпущен и уже в возрасте. Еще только несколько новостей / статей / сообщений в блоге / впечатлений. Я скептически Все еще в ожидании следующего основного выпуска Richfaces / Icefaces, который полностью поддерживает jsf 2 - в настоящее время могут быть загружены только альфа-сборки.

Struts 2 - Кажется, это хорошо, если вы все еще полагаетесь на Struts и хотите реорганизовать большую часть своего кода. В противном случае: нет.

GWT - мне не нравится одностраничный подход и подход java-> javascript. Я не уверен, если один сеанс - несколько представлений / окон могут быть легко достигнуты. Для меня этот фреймворк следует использовать для интернет-приложений с широкими окнами для одного пользователя.

Калитка - Хороший подход, но немного многословно и слишком мало документации доступно (кроме хорошей калитки в книге действий, но это касается только 1.3). Кроме того, для меня не хватает больших проектов, которые построены на нем сверху. И я в настоящее время не могу видеть, куда ведет дорога калитки или она уже загнала в тупик.

Spring MVC - еще не пробовал, но вам нужно включить много jar (spring mess) в ваш classpath для правильной работы с этим фреймворком. И это опирается на JSP (в большинстве проектов), который я считаю уже мертвым. И вы получаете только чистый MVC-фреймворк - все остальные вещи (ajax и другие) должны быть реализованы / интегрированы.

Полосы - небольшая и хорошо разработанная инфраструктура MVC, но слишком мало документации, слишком мало коммитов / коммиттеров, слишком мало релизов, слишком мало поддержки отрасли, слишком мало активности в списке рассылки.

Мне также любопытно, пропустил ли я какую-то основную структуру (я намеренно оставил «Гобелен»), что может быть вариантом для вас (и для меня тоже).


Я обнаружил, что лучший способ справиться с этим аналогичен тому, что сделали веб-фреймворки Python: выбирай и выбирай из лучших. Например: Spring + JAX-RS
Адам Гент

Ваши комментарии о GWT неверны. Довольно легко иметь много отдельных страниц, а не одну большую вещь. Вставьте ссылку на другую страницу, чтобы начать еще одно «действие» и все хорошо.
мП

Я также говорю о нескольких окнах (или вкладках). Действительно ли возможно использовать более одного окна, используя один и тот же сеанс одновременно?
MRalwasser

1
+1 Почему этот пост получил 2 отрицательных голоса? Подобные скептические мнения одинаково важны (если не больше), чем положительные! И они кажутся мне конструктивными.
Петр Собчик

8

Я имел большой успех с JAX-RS . Это единственная Java Web Framework, которая имеет какую-то спецификацию JSR и несколько реализаций, отличных от спецификации сервлета и портлета (хотя это может быть плохо).

Что плохо и хорошо в Java, так это то, что вы можете выбирать и сопоставлять фреймворки (в python также есть эта особенность / проблема). Это хорошо, потому что вам не нужно класть все яйца в одну корзину.

Вот общий рецепт стека веб-приложений Java:

Javascript / Flash + обработка запросов / ответов + внедрение зависимостей + постоянство

Javascript: JQuery, Prototype, Dojo

Запрос / ответ: Spring MVC, Stripes и мой любимый JAX-RS (Джерси, Apache CXF)

Инъекция зависимости: Весна, Guice

Упорство: JPA (Hibernate, хранилище Google App), Hibernate, JDO и многое другое.

У меня также был большой успех в использовании AspectJ, чтобы Java «меньше сосал». Используя миксины Spring @Configurable и AspectJ ITD, вы можете получить Rails как объекты Domain (это фактически то, что делает Roo, но вам не нужен Roo для этого).


4
Я согласен. Для создания собственного стека требуется больше времени, но тогда вы получите именно то, что хотите. В настоящее время я использую jQuery, Джерси, Spring и JPA2. JAX-RS великолепен, потому что вы полностью контролируете свой ответ.
Брайан ДиКаса

6

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


5

Посмотрите на RESThub , который следует тем же принципам, что и Play! но реализовано путем повторного использования некоторых инфраструктур / инструментов корпоративного уровня, таких как Maven 3 / Spring 3 / Jersey / jQuery.

RESThub очень разрушительный по сравнению с другими средами, поскольку он представляет собой полный набор инструментов стека, но без каких-либо серверных MVC или фреймворков на основе сервлетов. Вместо этого он использует графический интерфейс на основе пользовательского интерфейса jQuery, который использует веб-сервисы JAX-RS (REST), и систему шаблонов Javascript, основанную на встроенных файлахJ.

Серверы не сохраняют состояния, и мы используем сеанс HTML5 для сохранения сеанса на стороне клиента. Этот подход разработан для RIA и масштабируемости.

Некоторые демонстрационные приложения предоставляются (даже если в стадии разработки).


3

JSF - хороший фреймворк, но JSF 1.2 не хватало видения в течение многих лет после его выпуска. JSF 2.0 выглядит многообещающе и имеет много новых вещей, добавленных из JSF 1.2, таких как поддержка ajax, facelets, поддержка аннотаций и соглашения по умолчанию (меньше XML), простое создание компонентов, чем 1.2.

Он также хорошо интегрируется с Spring, если вы заинтересованы в поддержке DI.


2

Я бы рекомендовал весеннюю рекомендацию. Я не большой поклонник GWT, я не думаю, что кросс-компилятор Java -> Javascript еще там. Я работаю над приложением AJAX, которое использует Spring на сервере и jQuery на клиенте. Хотя технически нет встроенной поддержки jQuery, реализация Spring-MVC AjaxView очень проста и занимает около 25 строк кода.


2

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


1
Я использую vaadin, просто не подходит для создания сложных приложений.
Радан


1

Я думаю, что вы ищете что-то близкое к Джахии. Он поддерживает GWT, Mashups, медиа-контент и т. Д.

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templates http://www.jahia.net/downloads/jahia/jahia6.0.0/readme/index.html


Выглядит хорошо! Это открытый исходный код / ​​бесплатно для предприятия? Это широко используется?
космос

Он имеет версию для сообщества со всеми базовыми материалами, а также версию для предприятий с некоторыми дополнениями и т. Д. Проверьте это место jahia.com/jahia/Jahia
Syed M Shaaf


1

Посмотрите на ItsNat

ItsNat в основном браузер Java W3C в сервере, удивительно простой (DHTML сервер), продвигая AJAX интенсивного одностраничный интерфейса приложений


Ничего подобного полностью документированной демонстрации возможностей фреймворка: innowhere.com/itsnat/…
Равиндранат Акила

0

То, что заслуживает большего, чем просто пуля, - это основанные на плеерах интегрированные среды RIA. Ex. Adobe Flex + Java (Конечно, это может зависеть от того, действительно ли ваш «сайт» является «сайтом» или, скорее, «приложением», вы бы не создавали сайт блога во Flex.)

Ajax,

В смысле AJAX-как-умное слово Flex обычно использует AMF (двоичный протокол, который более эффективен, чем протоколы, используемые приложениями AJAX), хотя вы также можете делать строго AJAX с Flex. Таким образом, Flex поддерживает AJAX, но также поддерживает «лучше, чем AJAX».

мультимедийный контент, коллаж,

Поскольку Flex работает на платформе «виртуальной машины» Flash, я думаю, что мало что нужно добавить.

макеты на основе шаблонов,

Не уверен, к чему это приводит, но звучит как Flex mxml.

Проверка,

Конечно, поддерживается, хотя вы можете решить сделать что-то особенное, если захотите. (Не обязательно.) Приятно то, что вы можете стать настолько изощренным, насколько захотите - или нет.

максимальное разделение HTML / Java кода

Вы не можете получить больше разделения, используя подход к разработке «виртуальной машины», такой как Flex / Silverlight / JavaFX. Это не только позволяет вам отделить код презентации от логики на стороне сервера и уровня доступа к данным, но и гарантирует их разделение. «Виртуализация» вашей среды разработки обеспечивает кросс-браузерную совместимость, единую целевую платформу, не нужно беспокоиться о новых браузерах или новых выпусках браузеров, которые могут испортить ваше приложение, лучшие возможности отладки, подобные Java, и более профессиональный / впечатляющий внешний вид конечного продукта. ,

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.