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

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

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

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

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

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

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

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

Любое понимание использования 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 есть несколько поклонников .

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

• Сравнение JSF, Spring MVC, Stripes, Struts 2, Tapestry и Wicket (все еще не устарело)
• Веб-фреймворки будущего: Flex, GWT, Rails и Grails (просто чтобы почувствовать вкус альтернатив)
• Сравнение фреймворков Kick-Ass Web (это самая последняя версия)

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

Я использовал 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

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

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

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

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

• JSF
• Spring MVC
• Struts 2

Oни:

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

Игра очень похожа на ROR, версию ROR в Java

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

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

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

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

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

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

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

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

Я имел большой успех с 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 для этого).

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

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

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

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

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

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

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

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

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

Ext GWT + Spring

Я думаю, что вы ищете что-то близкое к Джахии. Он поддерживает 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

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ BACKBASE PORTAL

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

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

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

То, что заслуживает большего, чем просто пуля, - это основанные на плеерах интегрированные среды 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, и более профессиональный / впечатляющий внешний вид конечного продукта. ,