Каковы плюсы и минусы разных веб-фреймворков Java?
Я подумываю о создании собственного веб-сайта с использованием Java и пытаюсь решить, какую среду использовать. Однако при быстром поиске Java-фреймворков вы получите более 50 вариантов на выбор!
Мой сайт просто предназначен для моего собственного удовольствия от его создания в начале, но если он станет популярным, было бы хорошо, если бы он имел некоторую масштабируемость или, по крайней мере, был бы в состоянии изменить дизайн для этого.
Каковы основные различия между более популярными фреймворками? Есть ли случаи, когда один значительно превосходит другие? Например, корпоративные приложения с большим трафиком по сравнению с небольшими приложениями с низким трафиком. Мне также интересно, намного ли легче изучать и использовать некоторые, чем другие.
Есть ли кто-нибудь, кто имеет опыт работы с некоторыми из этих платформ и может дать рекомендацию? Является ли огромное количество вариантов просто ранним предупреждением, чтобы по возможности избежать веб-разработки на основе Java?
24 ответа
Я довольно широко использовал Tapestry 3, Wicket, Echo и JSF. Я бы порекомендовал вам просмотреть их и выбрать тот, который кажется вам наиболее простым и наиболее подходящим для вашей работы.
Из них мне было удобнее всего работать с Wicket из-за легкого характера компоновки компонентов и простоты шаблонизации страниц. Это происходит вдвойне, так что если вы используете свой собственный код БД вместо Hibernate или какой-либо другой инфраструктуры (я никогда не был полностью доволен Wicket Hibernate или Spring Integration).
Эхо замечательно, если вы не против написать все свои макеты на Java. Я знаю, что сейчас все по-другому, но я все еще думаю, что продукт занимает довольно узкую нишу. Кажется, они также меняют модель разработки с каждым основным выпуском.
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. Если вы ищете платформу, основанную на запросах, которая действительно проста в использовании, но не накладывает никаких ограничений на то, что вы делаете, я настоятельно рекомендую ее.
Это похоже на распорки, но выходит далеко за рамки. Есть даже некоторые проекты плагинов, которые позволяют вам использовать hibernate или jpa с очень небольшой конфигурацией.
Есть много хороших фреймворков, хотя я слышал, что калитка тоже хорошая, но я ею не пользовался.
Сам не пробовал, но думаю
имеет большой потенциал...
Исходя из php и classic asp, это первый java веб-фреймворк, который звучит многообещающе для меня....
ОБНОВЛЕНИЕ: Гобелен 5.2 отсутствует, поэтому он не заброшен, как это было раньше. Мой опыт работы с Гобеленом 4, а не 5, поэтому ваш пробег может отличаться. Мое мнение о Гобелене изменилось за эти годы; Я изменил этот пост, чтобы отразить его.
Я больше не могу рекомендовать Гобелен, как раньше. Гобелен 5, кажется, значительное улучшение, но моя главная проблема с Гобеленом не связана с самой платформой; это с людьми, стоящими за этим.
Исторически, каждое крупное обновление версии Tapestry нарушало обратную совместимость с крайними предубеждениями, гораздо больше, чем можно было ожидать. По-видимому, это связано с внедрением новых методов или технологий кодирования, которые требуют значительных изменений.
Говард Льюис Шип (основной автор Tapestry), безусловно, блестящий разработчик, но я не могу сказать, что мне небезразлично его руководство проектом Tapestry. Разработка Tapestry 5 началась почти сразу же после поставки Tapestry 4. Судя по тому, что я могу сказать, Корабль в значительной степени посвятил себя этому, оставив Tapestry 4 в руках других участников, которые, как я чувствую, не так способны, как Корабль. Сделав болезненный переход от Гобелена 3 к Гобелену 4, я почувствовал, что меня покинули почти сразу.
Конечно, с выпуском Tapestry 5 Tapestry 4 стал устаревшим продуктом. У меня не было бы проблемы с этим, если бы путь обновления не был таким жестоким снова. Так что теперь наша команда разработчиков находится в довольно незавидном положении: мы могли бы продолжать использовать практически заброшенную веб-платформу (Tapestry 4), сделать отвратительное обновление до Tapestry 5 или полностью отказаться от Tapestry и переписать наше приложение, используя другую платформу. Ни один из этих вариантов не очень привлекателен.
Гобелен 5 предположительно написан так, чтобы уменьшить вероятность поломки обновления с этого момента. Хороший пример - классы страниц: в предыдущих воплощениях классы страниц произошли от базового класса, предоставленного Tapestry; несовместимые изменения API в этом классе стали причиной большого количества проблем с обратной совместимостью. В Tapestry 5 страницы представляют собой POJO, которые улучшаются во время выполнения с помощью "волшебной волшебной пыли Гобелена" посредством аннотаций. Таким образом, пока поддерживается контракт на аннотации, изменения в Tapestry не будут влиять на классы ваших страниц.
Если это правильно, то написание нового приложения с использованием Tapestry 5 может оказаться удачным. Но лично мне не хочется снова класть руку на горелку.
Отказ от ответственности: я работаю в Vaadin (ранее IT Mill)
Если вы делаете что-то RIAish, вы можете взглянуть на Vaadin. Это AJAX-фреймворк с открытым исходным кодом, который мне нравится использовать (я сам пришел из PHP).
Есть пример, в котором сравнивается использование одного и того же приложения (то есть двух приложений с одинаковым набором функций) в Icefaces и Vaadin. В двух словах, говорится, что разработка пользовательского интерфейса была значительно быстрее.
Несмотря на то, что исследование проводится на вики компании, я могу заверить, что оно объективное, подлинное и правдивое, хотя я не могу заставить вас поверить мне.
После долгих испытаний различных решений для меня это оказалось:
Spring MVC для уровня представления и контроллера (хотя Spring Webflow НЕТ, потому что мои потоки основаны на ajax)
JQuery для всего на стороне клиента
Spring Security с точки зрения безопасности
Hibernate / JPA2
Причал ради продолжения (комета)
Один месяц необычайно крутой кривой обучения, но теперь я счастлив.
Я также хотел бы отметить, что я был всего в нескольких шагах от того, чтобы пропустить все эти вещи Java и использовать вместо этого Scala/LIFT. Насколько мне известно, все, что связано с ультрасовременной веб-разработкой в Java (кометы, асинхронное общение, безопасность (да, даже с Spring Security!)), Все еще является чем-то вроде взлома (докажите, что я не прав, используя доказательства, pleeease!). На мой взгляд, Scala/LIFT - это более готовое и универсальное решение.
Причина, по которой я наконец решил не ездить со Scala, заключается в том, что
как руководитель проекта, я должен учитывать человеческие ресурсы, и разработчиков на Java гораздо проще найти, чем разработчиков Scala
Для большинства разработчиков в моей команде функциональную концепцию Scala, как бы она ни была великолепна, трудно понять.
Ура Эр
Я тоже слышал хорошие вещи о Spring Framework. В целом, однако, я был в восторге от большинства веб-фреймворков Java, на которые я смотрел (особенно Struts).
Для простого приложения я бы определенно подумал об использовании "сырых" сервлетов и JSP и не беспокоился о принятии фреймворка. Если сервлеты хорошо написаны, в будущем должно быть просто портировать на среду, если это необходимо, когда приложение усложняется.
Я думаю, что для ваших скромных требований вам просто нужно кодировать сервлеты или простые страницы JSP, которые вы можете обслуживать с сервера Tomcat. Я не думаю, что вам нужны какие-либо веб-фреймворки (например, Struts) для личных данных веб-сайта
Сказать "использовать JSF" немного проще. Когда вы решите использовать JSF, вы должны выбрать библиотеку компонентов поверх нее. Будете ли вы использовать MyFaces Tomahawk, Тринидад, Тобаго ( http://myfaces.apache.org/)? Или, может быть, ICEfaces ( http://www.icefaces.org/)? О, и если вы будете использовать ICEfaces, будете ли вы использовать JSP или Facelets для своих представлений?
По моему это трудно сказать. Ни у кого нет времени, чтобы оценить все многообещающие альтернативы, по крайней мере, в проектах, над которыми я работаю, потому что они недостаточно велики, чтобы выполнить трехмесячные этапы оценки. Тем не менее, вы должны искать тех, кто имеет большое и активное сообщество и не ушел в течение года. JSF существует уже некоторое время, и, так как на него надвигается солнце, он будет вокруг еще немного. Я не могу сказать, является ли это лучшим выбором, но он будет хорошим.
Для сайтов с высоким трафиком я бы использовал инфраструктуру, которая не управляет состоянием клиента на сервере - Wicket, JSF и Tapestry управляют состоянием клиента на сервере. Я бы использовал эти фреймворки (Wicket - мой любимый), если приложение должно быть больше похоже на настольное приложение. Но я бы попробовал использовать более масштабируемый и простой подход REST+AJAX.
Spring MVC был бы кандидатом, но начиная с Spring MVC 3, он имеет странную аннотированную перегруженную модель программирования, которая не использует преимущества статической типизации. Есть и другие уродливые вещи, такие как выходные параметры в методах в сочетании с обычным возвратом, поэтому у одного метода есть два выходных канала. Spring MVC также имеет тенденцию заново изобретать колесо, и вам придется настраивать больше по сравнению с другими фреймворками. Я не могу порекомендовать Spring MVC, хотя у него есть хорошие идеи.
Grails - это удобный способ использования Spring MVC и других установленных сред, таких как Hibernate. Кодирование это весело, и вы быстро увидите результаты.
И не забывайте, что Servlet API с несколькими маленькими помощниками, такими как FreeMarker для создания шаблонов, очень мощный.
Я оценил довольно много фреймворков, и Ваадин ( http://vaadin.com/home) проскочил до самого верха.
Вы должны по крайней мере дать ему краткую оценку.
Ура!
Мой выбор - Wicket (для крупных проектов и предсказуемой базы пользователей), GWT (для крупных проектов, в основном общедоступных) или просто сервисная структура (например, Jersey/ JAXRS) вместе с инструментарием JavaScript (для небольших и средних проектов),
Для быстрого и интересного графического интерфейса вы можете использовать JSF с библиотекой Richfaces. Компоненты пользовательского интерфейса Richfaces просты в использовании и имеют удобные ссылки с демонстрацией кода на демонстрационном сайте. Возможно, позже, когда ваш сайт будет иметь больше данных для обработки, и большая часть информации будет передаваться в базу данных, вы можете подключить к ней любую инфраструктуру доступа к базе данных (ORM).
Посмотрите несколько комментариев о некоторых фреймворках Java-приложений (второй абзац):
http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html
Мой любимый способ использовать действительно простые приложения - это Apache VelocityTools (VelocityLayoutServlet) с Velosurf ( http://velosurf.sourceforge.net/).
Для более сложных приложений Spring MVC или Struts 2.