Каковы плюсы и минусы различных веб-фреймворков Java? [закрытый]
Я рассматриваю возможность создания собственного веб-сайта с помощью Java и пытаюсь решить, какую структуру использовать. Тем не менее, быстрый поиск фреймворков Java возвращает более 50 на выбор!
мой сайт просто будет для моего собственного удовольствия от его создания в начале, но если он станет популярным, было бы хорошо, чтобы он имел некоторую масштабируемость или, по крайней мере, был в состоянии перепроектировать для этого.
каковы основные различия между более популярными рамки? Есть ли случаи, когда один значительно превосходит другие? Например, корпоративные приложения с высоким трафиком по сравнению с малыми приложениями с низким трафиком. Мне также интересно, намного ли некоторые из них легче учиться и использовать, чем другие.
кто-нибудь имеет опыт работы с некоторыми из этих рамок и может дать рекомендацию? Является ли огромное количество вариантов просто ранним предупреждением, чтобы избежать веб-разработки на основе Java, где это возможно?
24 ответов
Я использовал гобелен 3, калитка, Эхо и JSF довольно обширно. Я бы очень рекомендовал вам просмотреть их и выбрать тот, который кажется вам самым легким, и наиболее точно соответствовать тому, как вы предпочитаете работать.
из них самым удобным для меня было работать с калитка, должный к облегченному характеру компонентного здания и простоте страницы templating. Это происходит вдвойне, если вы использование собственного кода БД вместо гибернации или какой-либо другой структуры (я никогда не был полностью доволен гибернацией или весенней интеграцией).
Эхо отлично, если вы не против написать весь свой макет на Java. Я знаю, что сейчас все по-другому, но я все еще думаю, что продукт служит довольно узкой нише. Они также меняют модель разработки с каждым крупным выпуском.
гобелен - это отличный продукт, но это очевидно очень отличается от других с точки зрения модели развития, поскольку ее ведет в основном один чувак. Корабль Говарда Льюиса, без сомнения, довольно умен, но я разочарован их решением в основном забыть обратную совместимость с каждым выпуском. Опять же, для ваших нужд это может не иметь значения, и я всегда находил гобеленовые продукты приятными для работы.
JSF уже в течение многих лет, и до сих пор чувствует, как что-то, что распорок парень построен исправить все проблемы стояков. Не понимая по-настоящему всех проблем со стойками. Оно все еще имеет незаконченное чувство к ему, хотя продукт очевидно очень гибок. Я использую его и испытываю к нему некоторую привязанность, с большими надеждами на его будущее. Я думаю, что следующий выпуск (2.0), который будет доставлен в JEE6, действительно принесет его в свой собственный, с новым синтаксисом шаблона (похожим на Facelets) и упрощенной моделью компонентов (пользовательские компоненты только в 1 файле... окончательно.)
и, конечно же, есть миллион меньших фреймворков и инструментов, которые получают свои собственные следующие (скорость для основных потребностей, raw JSPs, распорки, etc). Однако я обычно предпочитаю компонентно-ориентированные фреймворки.
в конце концов, я бы рекомендовал просто взглянуть на гобелен, калитку и JSF и просто выбрать тот, который чувствует себя лучше для вас. Вы, вероятно, найдете тот, который просто подходит к вам как на работу быстро.
мой любимый-весенние рамки. С 2.5 Spring MVC - это soooo kick ass, с новыми аннотациями,соглашением по функциям конфигурации и т. д.
Если вы просто делаете что-то супер простое, вы также можете попробовать использовать обычный API сервлетов и не беспокоиться о фреймворке.
Я рекомендую компонент, ориентированный калитка основы. Это позволяет писать веб-приложение в простой старый код Java, вы можете использовать POJOs в качестве модели для всех компонентов и не нужно возиться с огромными файлами конфигурации XML.
Я успешно разработал приложение онлайн-банкинга со стойками, когда я обнаружил калитку и увидел, как легко разработка веб-приложений может быть!
недавно я начал использовать Stripes Framework. Если вы ищете фреймворк на основе запросов, который очень прост в использовании, но не накладывает никаких ограничений на то, что вы делаете, я настоятельно рекомендую его.
Это похоже на распорки, но это выходит за рамки его. Есть даже некоторые проекты плагинов, которые позволяют использовать hibernate или jpa с очень небольшой конфигурацией.
есть много хороших рамок, хотя я слышал, что калитка хороший, но я им не пользовался.
сам не пробовал, но думаю
большой потенциал...
исходя из php и классического asp, это первая веб-платформа java, которая звучит многообещающе для меня....
UPDATE: гобелен 5.2 отсутствует, поэтому он не заброшен, как казалось ранее. Мой опыт работы с гобеленом 4, а не 5, поэтому ваш пробег может отличаться. Мое мнение о гобелене изменилось с годами; я изменил этот пост, чтобы отразить его.
Я больше не могу рекомендовать гобелен, как я делал раньше. Гобелен 5 кажется значительным улучшением, но моя главная проблема с гобеленом не с самой платформой; это с людьми позади он.
исторически, каждое крупное обновление версии гобелена нарушило обратную совместимость с крайним предубеждением, гораздо больше, чем можно было ожидать. Это, по-видимому, связано с внедрением новых методов или технологий кодирования, которые требуют значительных переписок.
Говард Льюис шип (главный автор гобеленов), безусловно, блестящий разработчик, но я не могу сказать, что я забочусь о его управлении проектом гобеленов. Развитие гобелен 5 стал почти сразу после того, как гобелен 4 отгрузили. Из того, что я могу сказать, корабль в значительной степени посвятил себя этому, оставив гобелен 4 в руках других участников, которые, я чувствую, не так способны, как корабль. После болезненного перехода с гобелена 3 на гобелен 4 я почувствовал, что меня почти сразу бросили.
конечно, с выпуском гобелена 5, гобелен 4 стал продуктом наследия. У меня не было бы проблем с этим, если бы путь обновления не был таким жестоким снова. Итак, теперь наша команда разработчиков находится в довольно незавидном положении: мы можем продолжать использовать по существу заброшенную веб-платформу (гобелен 4), сделать отвратительное обновление до гобелена 5 или полностью отказаться от гобелена и переписать наше приложение, используя другую платформу. Ни один из этих вариантов не очень привлекателен.
гобелен 5 предположительно написан так, чтобы уменьшить вероятность поломки обновления с этого момента. Хорошим примером является класс page: в предыдущих воплощениях классы страниц происходили из базового класса, предоставляемого гобеленом; несовместимые изменения API в этом классе были причиной большого количества проблем обратной совместимости. В гобелене 5 страницы POJOs, которые улучшаются во время выполнения с помощью" волшебного гобелена fairy dust " с помощью аннотаций. Пока сохраняется контракт для аннотаций, изменения в гобелен не повлияют на классы страниц.
Если это правильно, то писать новую заявку Гобелен 5 может получиться хорошо. Но лично мне не хочется снова класть руку на горелку.
Disclamer: я работаю в Vaadin (ранее это мельница)
Если вы делаете что-то RIAish, вы можете взглянуть на фреймворк Vaadin. Это платформа AJAX с открытым исходным кодом, ориентированная на пользовательский интерфейс, которую мне приятно использовать (я сам из PHP-фона).
здесь кейс это сравнивает выполнение одного и того же приложения (т. е. двух приложений с одинаковым набором функций) в Icefaces и Vaadin. В двух словах, он гласит: что разработка пользовательского интерфейса была значительно быстрее.
несмотря на то, что исследование размещено в wiki компании, я могу заверить, что оно объективно, искренне и правдиво, хотя я не могу заставить вас поверить мне.
после долгого тестирования различных решений, для меня это оказалось:
Spring MVC для презентации и слой контроллера (без Spring Webflow, потому что мои потоки основаны на ajax)
jQuery для всех материалов на стороне клиента
Spring Security для, ну, аспект безопасности
Hibernate / JPA2
причал ради продолжение (комета)
один месяц необычайно крутой кривой обучения, но теперь я счастлив.
Я также хотел бы упомянуть, что я был всего в нескольких шагах от пропуска всего этого Java-материала и изучения Scala/LIFT. Насколько мне известно, все в Java, что связано с передовой веб-разработкой (comet, async communication,безопасность (да, даже с весны безопасности!)) все еще немного взлом (proove me неверно по уликам, пожалуйста!). Для меня Scala / LIFT кажется более нестандартным и универсальным решением.
Почему я, наконец, решил не идти с Scala это
как руководитель проекта я должен учитывать человеческие ресурсы и разработчиков Java гораздо проще найти, чем разработчиков Scala
для большинства разработчиков в моей команде, функциональная концепция Scala, как отлично, как это, трудно пойми!--1-->
Ура Эр
Я тоже слышал хорошие вещи о весенней структуре. В общем, хотя, я был в восторге от большинства веб-фреймворков Java, на которые я смотрел (ESP Struts).
для простого приложения я бы определенно рассмотрел использование" сырых " сервлетов и JSPs и не беспокоиться о принятии структуры. Если сервлеты хорошо написаны, в будущем должно быть просто портировать на фреймворк, если это необходимо, когда приложение усложняется.
Я думаю, что для ваших скромных требований вам просто нужно закодировать сервлеты или простые страницы jsp, которые вы можете обслуживать с сервера Tomcat. Я не думаю, что вам нужен какой-либо веб-фреймворк (например, struts) для персональных данных веб-сайта
сказать "использовать JSF" немного просто. Когда вы решите использовать JSF, вы должны выбрать библиотеку компонентов на ней. Вы будете использовать MyFaces Томагавк, Тринидад, Тобаго (http://myfaces.apache.org/)? Или, может быть, ICEfaces (http://www.icefaces.org/)? Ну, а если вы используете ICEfaces, вы будете использовать JSP и facelets для ваших взглядов?
на мой взгляд это трудно сказать. Никто не успевает оценить все перспективные альтернативы, по крайней мере в проекты, над которыми я работаю, потому что они недостаточно велики для трехмесячных этапов оценки. Тем не менее, вы должны искать тех, кто имеет большое и активное сообщество и не ушел через год. JSF существует некоторое время, и так как его толкает солнце, он будет еще некоторое время. Я не могу сказать, лучший ли это выбор, но он будет хорошим.
для сайтов с высоким трафиком я бы использовал фреймворк, который не управляет состоянием клиента на сервере - калитка, JSF и гобелен управляют состоянием клиента на сервере. Я бы использовал только эти фреймворки (калитка-моя любимая), если приложение должно быть больше похоже на настольное приложение. Но я бы попытался использовать более масштабируемый и простой подход REST+AJAX.
Spring MVC будет кандидатом, но поскольку Spring MVC 3 имеет странную аннотацию, перегруженную моделью программирования, которая не использует преимущества статического ввода. Есть и другие уродливые вещи, такие как выходные параметры в методах в сочетании с обычным возвратом, поэтому есть два выходных канала одного метода. Весна MVC также имеет тенденцию к reeinvent колесо и вы будете иметь больше, чтобы настроить по сравнению с другими платформами. Я не могу рекомендовать Spring MVC, хотя у него есть некоторые хорошие идеи.
Grails-удобный способ использовать Spring MVC и другие установленные фреймворки, такие как Hibernate. Кодирование-это весело, и вы будете быстро увидеть результаты.
и не забывайте, что API сервлета с несколькими маленькими помощниками, такими как FreeMarker для шаблонов, очень мощный.
Я оценил довольно много фреймворков и Vaadin (http://vaadin.com/home) просочился до самого верха.
вы должны по крайней мере дать ему краткую оценку.
Ура!
мой выбор будет калиткой (для крупных проектов и предсказуемой пользовательской базы), GWT (для крупных проектов, которые в основном являются общедоступными) или просто платформой обслуживания (например, Jersey/ JAXRS) вместе с набором инструментов JavaScript (для малых и средних проектов).
см. несколько комментариев к некоторым фреймворкам приложений Java (второй абзац):
http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html
на быстрая и навороченная GUI вы можете использовать JSF с Richfaces библиотека. Компоненты интерфейса Richfaces просты в использовании и удобны в использовании с демонстрацией кода на демо-сайте. Вероятно, позже, когда на вашем сайте будет больше данных для обработки и много информации должно быть обработано в базе данных, вы можете подключить к ней любую структуру доступа к базе данных (ORM).
мой любимый способ пойти для действительно простых приложений Apache VelocityTools (VelocityLayoutServlet) с Velosurf (http://velosurf.sourceforge.net).
для более сложных приложений, Spring MVC или Struts 2.