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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

Юридическая информация: Я работаю в Vaadin (ранее IT Mill)

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

Я больше не могу рекомендовать Гобелен, как и раньше. Гобелен 5 кажется значительным улучшением, но моя главная проблема с 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 может получиться хорошо. Но лично я не чувствую, что снова положил руку на горелку.

Answer 9

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

Answer 10

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

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

Answer 11

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

Answer 12

Мой выбор является Калитка !!

Answer 13

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

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

Answer 14

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

Answer 15

не пробовал сам, но я думаю, что

http://www.playframework.org/

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

исходя из PHP и классический осины , это первый java-веб-фрейм, который кажется мне перспективным ....

Answer 16

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

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

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

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

Answer 17

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

Answer 18

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

Answer 19

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

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

Cheers!

Answer 20

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

Answer 21

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

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

Answer 22

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

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

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

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

• Hibernate/JPA2

• Jetty ради продолжений (кометы)

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

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

Причина, почему я, наконец, решил не идти с Scala является

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

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

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

Answer 23

Я бы сказал vaadin или wicket

Answer 24

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