Каковы плюсы и минусы различных веб-фреймворков Java? [закрыто]

Я подумываю о создании собственного веб-сайта на Java и пытаюсь решить, какую структуру использовать. Однако быстрый поиск фреймворков Java возвращает более 50 на выбор!

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

Каковы основные различия между наиболее популярными фреймворками? Бывают ли случаи, когда один значительно превосходит другие? Например, корпоративные приложения с высоким трафиком по сравнению с небольшими приложениями с низким трафиком. Мне также интересно, намного ли легче выучить и использовать одни, чем другие.

Есть ли кто-нибудь, кто имеет опыт работы с некоторыми из этих фреймворков и может дать рекомендации? Является ли огромное количество вариантов лишь ранним предупреждением о необходимости избегать веб-разработки на основе Java там, где это возможно?

Я довольно широко использовал Tapestry 3 , Wicket , Echo и JSF . Я действительно рекомендую вам просмотреть их и выбрать тот, который кажется вам самым простым и наиболее точно соответствует вашему стилю работы.

Из них наиболее удобным для меня был Wicket из-за легкости построения компонентов и простоты создания шаблонов страниц. Это вдвойне, если вы используете свой собственный код db вместо Hibernate или какой-либо другой структуры (я никогда не был полностью доволен Wicket Hibernate или Spring Integration).

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

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

JSF отсутствует уже много лет и до сих пор кажется чем-то, что разработчик Struts построил для решения всех проблем Struts. Без понимания всех проблем со Struts. Он по-прежнему выглядит незавершенным, хотя продукт, очевидно, очень гибкий. Я использую его и испытываю к нему некоторую привязанность и с большими надеждами на его будущее. Я думаю, что следующий выпуск (2.0), который будет доставлен в JEE6, действительно внесет его в свой собственный, с новым синтаксисом шаблона (похожим на Facelets) и упрощенной компонентной моделью (пользовательские компоненты только в 1 файле ... наконец).

И, конечно же, есть миллион более мелких фреймворков и инструментов, у которых есть собственные подписчики ( Velocity для базовых нужд, сырые JSP , Struts и т. Д.). Я вообще предпочитаю компонентно-ориентированные фреймворки.

В конце концов, я бы рекомендовал просто взглянуть на Tapestry, Wicket и JSF и просто выбрать тот, который вам больше всего нравится. Вы, вероятно, очень быстро найдете тот, который подходит именно вам.

Мне больше всего нравится Spring Framework. С 2.5 Spring MVC оооочень крутой, с новыми аннотациями, соглашениями по функциям конфигурации и т. Д.

Если вы просто делаете что-то очень простое, вы можете просто попробовать использовать обычный Servlet API и не беспокоиться о фреймворке.

Я рекомендую компонентно-ориентированный фреймворк Wicket . Он позволяет вам писать свое веб-приложение в простом старом Java-коде, вы можете использовать POJO в качестве модели для всех компонентов и вам не нужно возиться с огромными файлами конфигурации XML.

Я успешно разработал приложение для онлайн-банкинга с помощью Struts, когда обнаружил Wicket и увидел, насколько простой может быть разработка веб-приложений!

Недавно я начал использовать Stripes Framework . Если вы ищете платформу на основе запросов, которая действительно проста в использовании, но не налагает никаких ограничений на то, что вы делаете, я настоятельно рекомендую ее.

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

Есть много хороших фреймворков, хотя я слышал, что калитка тоже хорошая, но я ее не использовал.

Сам не пробовал, но думаю

http://www.playframework.org/

имеет большой потенциал ...

исходящий от php и классического asp, это первый веб-фреймворк java, который звучит многообещающе для меня ...

ОБНОВЛЕНИЕ: Гобелен 5.2 вышел, поэтому он не заброшен, как раньше. Мой опыт работы с Tapestry 4, а не 5, поэтому ваш опыт может отличаться. Мое мнение о Tapestry изменилось с годами; Я изменил этот пост, чтобы отразить это.

Я больше не могу рекомендовать Tapestry, как раньше. Tapestry 5 кажется значительным улучшением, но моя главная проблема с Tapestry не в самой платформе; это с людьми, стоящими за этим.

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

Говард Льюис Шип (главный автор Tapestry), безусловно, блестящий разработчик, но я не могу сказать, что мне небезразлично его руководство проектом Tapestry. Разработка Tapestry 5 началась почти сразу после поставки Tapestry 4. Насколько я могу судить, Корабль в значительной степени посвятил себя этому, оставив Tapestry 4 в руках других участников, которые, как мне кажется, не так хороши, как Ship. После болезненного перехода с Tapestry 3 на Tapestry 4 я почти сразу почувствовал, что меня бросили.

Конечно, с выпуском Tapestry 5, Tapestry 4 стала устаревшим продуктом. У меня не было бы проблем с этим, если бы путь обновления снова не был таким жестоким . Итак, теперь наша команда разработчиков находится в довольно незавидном положении: мы могли бы продолжать использовать практически заброшенную веб-платформу (Tapestry 4), сделать чудовищное обновление до Tapestry 5 или полностью отказаться от Tapestry и переписать наше приложение, используя другую платформу. Ни один из этих вариантов не очень привлекателен.

Гобелен 5 якобы написан так, чтобы с этого момента снизить вероятность поломки обновления. Хороший пример - классы страниц: в предыдущих воплощениях классы страниц происходили от базового класса, предоставленного Tapestry; несовместимые изменения API в этом классе стали причиной большого количества проблем с обратной совместимостью. В Tapestry 5 страницы - это объекты POJO, которые во время выполнения дополняются «волшебной волшебной пылью Tapestry» с помощью аннотаций. Таким образом, пока сохраняется контракт на аннотации, изменения Tapestry не повлияют на классы ваших страниц.

Если это верно, то написание нового приложения с использованием Tapestry 5 может оказаться удачным. Но лично мне не хочется снова класть руку на конфорку.

Предупреждение: я работаю в Vaadin (ранее IT Mill)

Если вы делаете что-то RIAish, вы можете взглянуть на Vaadin . Это AJAX-фреймворк с открытым исходным кодом, ориентированный на пользовательский интерфейс, который мне нравится использовать (я сам из PHP).

Существует тематическое исследование, в котором сравнивается выполнение одного и того же приложения (т.е. двух приложений с одинаковым набором функций) в Icefaces и Vaadin. В двух словах говорится, что разработка пользовательского интерфейса была значительно быстрее.

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

После долгого тестирования различных решений для меня это оказалось:

• Spring MVC для уровня представления и контроллера (НЕТ Spring Webflow, потому что мои потоки основаны на ajax)

• jQuery для всех вещей на стороне клиента

• Spring Security для аспекта безопасности

• Гибернация / JPA2

• Причал для продолжения (комета)

Один месяц необычайно крутой кривой обучения, но теперь я счастлив.

Я также хотел бы упомянуть, что я был всего в небольшом шаге от того, чтобы отказаться от всего этого Java и вместо этого изучать Scala / LIFT. Насколько мне известно, все в Java, что связано с передовой веб-разработкой (комета, асинхронная связь, безопасность (да, даже со Spring Security!)), Все еще является чем-то вроде взлома (докажите, что я ошибаюсь, доказательствами, пожалуйста !). Мне Scala / LIFT кажется более готовым и универсальным решением.

Причина, по которой я окончательно решил не использовать Scala, заключается в

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

• для большинства разработчиков в моей команде функциональную концепцию Scala, сколь бы прекрасной она ни была, трудно понять

Ура Эр

Я тоже слышал хорошие отзывы о Spring Framework. В целом, однако, большинство веб-фреймворков Java, на которые я смотрел (особенно Struts), меня не впечатлили.

Для простого приложения я бы определенно рассмотрел возможность использования «сырых» сервлетов и JSP и не беспокоился о принятии инфраструктуры. Если сервлеты хорошо написаны, в будущем будет проще переносить на фреймворк, если это необходимо, когда приложение становится все сложнее.

Мой выбор - Wicket !!

Все они - вот и проблема ;-)

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

Сказать «использовать JSF» - это немного просто. Когда вы решите использовать JSF, вы должны выбрать библиотеку компонентов поверх него. Будете ли вы использовать MyFaces Tomahawk, Тринидад, Тобаго ( http://myfaces.apache.org/ )? Или, может быть, ICEfaces ( http://www.icefaces.org/ )? О, и если вы используете ICEfaces, будете ли вы использовать JSP или Facelets для своих представлений?

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

http://zkoss.org - хороший

Для сайтов с высоким трафиком я бы использовал структуру, которая не управляет состоянием клиента на сервере - Wicket, JSF и Tapestry управляют состоянием клиента на сервере. Я бы использовал эти фреймворки (мой любимый Wicket), если приложение должно быть больше похоже на настольное приложение. Но я бы попытался использовать более масштабируемый и простой подход REST + AJAX.

Spring MVC был бы кандидатом, но, начиная с Spring MVC 3, он имеет странную модель программирования, перегруженную аннотациями, которая не использует преимущества статической типизации. Существуют и другие уродливые вещи, такие как выходные параметры в методах в сочетании с обычным возвратом, поэтому существует два выходных канала одного метода. Spring MVC также имеет тенденцию заново изобретать колесо, и вам придется больше настраивать по сравнению с другими фреймворками. Я не могу рекомендовать Spring MVC, хотя у него есть несколько хороших идей.

Grails - это удобный способ использования Spring MVC и других установленных фреймворков, таких как Hibernate. Кодировать - это весело, и вы быстро увидите результаты.

И не забывайте, что Servlet API с небольшими помощниками, такими как FreeMarker для создания шаблонов, очень мощный.

Я оценил довольно много фреймворков, и Vaadin ( http://vaadin.com/home ) просочился до самого верха.

Вы должны хотя бы дать ему краткую оценку.

Ура!

Я бы выбрал Wicket (для крупных проектов и предсказуемой базы пользователей), GWT (для крупных проектов, которые в основном общедоступны) или просто сервисный фреймворк (например, Jersey / JAXRS) вместе с инструментарием JavaScript (для малых и средних проектов) .

Я рекомендую Seam, особенно если вам нужна настойчивость.

См. Несколько комментариев к некоторым фреймворкам приложений Java (второй абзац):

http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html

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

Не могу поверить, что никто не упомянул GWT

Мой любимый способ создания действительно простых приложений - это Apache VelocityTools (VelocityLayoutServlet) с Velosurf ( http://velosurf.sourceforge.net ).

Для более сложных приложений Spring MVC или Struts 2.

Попробуйте HybridJava - это намного проще, чем что-либо еще.

Я бы сказал ваадин или калитка