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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

И, конечно же, есть миллионы меньших рамок и инструментов, которые получают свои собственные (Velocity для удовлетворения основных потребностей, raw JSPs, Struts и т.д.). Однако я вообще предпочитаю компоненты, ориентированные на компоненты.

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

Ответ 2

Моим любимым является Spring Framework. С 2.5 Spring MVC - это задняя задница с новыми комментариями, соглашениями о настройках и т.д.

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

Еще один, который следует рассмотреть, - это Grails.

Хотя это не строго структура Java, она зависит от Groovy (если вы этого раньше не видели, это динамический язык, который работает на JVM). Наиболее допустимая Java также действительна Groovy, поэтому ее довольно легко изучить.

Мой последний проект использовал Grails, и пока я никогда раньше не использовал Groovy, я обнаружил:

  • Groovy - это радость в использовании, гораздо больше удовольствия, чем Java
  • Существует очень небольшая конфигурация, нет XML, и вы работаете с полным приложением базы данных менее чем за час.

Существует недостаток: это очень "умная" структура, которая много скрывает от вас, поэтому, когда что-то идет не так, может потребоваться много времени, чтобы найти проблему.

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

(но +1 для Wicket и Stripes, две отличные рамки).

Ответ 6

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

http://www.playframework.org/

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

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

Ответ 7

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

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

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

Howard Lewis Ship (главный автор Tapestry), безусловно, блестящий разработчик, но я не могу сказать, что я забочусь о его управлении проектом Tapestry. Разработка Tapestry 5 началась почти сразу после отправки Tapestry 4. Из того, что я могу сказать, корабль в значительной степени посвятил себя этому, оставив Tapestry 4 в руках других участников, которые, как я чувствую, не так хороши, как корабль. Сделав мучительный переход от Tapestry 3 to Tapestry 4, я почувствовал, что меня практически покинули почти сразу.

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

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

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

Ответ 8

Disclamer: Я работаю в Vaadin (ранее IT Mill)

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

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

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

Ответ 9

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

  • Spring MVC для презентации и (NO Spring Webflow, хотя, потому что мои потоки основаны на ajax)

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

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

  • Hibernate/JPA2

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

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

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

Причина, по которой я, наконец, решил не идти с Scala, это

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

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

Приветствия Er

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

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

Ответ 16

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

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

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

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

Ответ 17

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

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

Ура!

Ответ 18

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

Ответ 19

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

Ответ 21

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

Ответ 22

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

Ответ 23

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

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

Ответ 24

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