Java EE 6 против стека Spring 3

Я начинаю новый проект сейчас. Я должен выбрать технологии. Мне нужно что-то легкое, так что нет EJB или Seam. С другой стороны, мне нужны JPA (Hibernate или альтернатива) и JSF с IceFaces.

Считаете ли вы, что такой стек на Spring 3, развернутый на Tomcat, является хорошим выбором? Или веб-приложение Java EE 6 может быть лучше? Я боюсь, что Java EE 6 - это новая технология, которая еще недостаточно документирована. Tomcat легче поддерживать, чем Glassfish 3.

Каково твое мнение? У вас есть опыт?

16 ответов

Мне нужно что-то легкое, так что нет EJB или Seam.

Не могли бы вы объяснить, что делает EJB тяжелыми после EJB3? Ты понимаешь, что мы больше не в 2004 году? Мне бы очень хотелось прочитать ваше определение света и ваши аргументы (и я с удовольствием обновлю свой ответ, потому что я почти уверен, что у меня будет несколько убедительных слов).

С другой стороны, мне нужны JPA (Hibernate или альтернатива) и JSF с IceFaces.

Java EE 6 Web Profile, который включает в себя JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI,... был бы идеальным для этого, и вы можете использовать GlassFish v3 Web Profile для запуска приложения, созданного с помощью Java EE 6 Web Profile.,

Считаете ли вы, что такой стек на Spring 3, развернутый на Tomcat, является хорошим выбором? Или веб-приложение Java EE 6 может быть лучше?

Ну, мне нравится идея запускать мой код на несвободной платформе (Java EE), а не на проприетарном контейнере (Spring). И я думаю, что Java EE 6 достаточно хорош (и это эвфемизм, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI, задница). Обратите внимание, что я был скептиком JSF, но я посмотрел второй раз, и JSF 2.0 с CDI настолько отличается, что я даже не могу сравнить. И если вы не смотрели на CDI, позвольте мне сказать вам, что это круто.

Я боюсь, что Java EE 6 - это новая технология, которая еще недостаточно документирована.

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

Tomcat легче поддерживать, чем Glassfish 3.

Вы что-нибудь пробовали? Сталкивались ли вы с какой-либо конкретной проблемой? Опять же, это звучит как бесплатный иск.

Я не использовал JavaEE6.

Тем не менее, все предыдущие версии JavaEE и EJB сильно избили меня, и я не буду доверять ему до тех пор, пока он не станет стандартом де-факто, а не просто стандартом де-юре. Прямо сейчас весна по-прежнему является стандартом де-факто.

Обмани меня один раз, позор вам. Обмани меня дважды, позор мне. Обмани меня три раза, EJB.

Некоторые утверждают, что Spring является частной собственностью. Я бы сказал, что реализации спецификаций JavaEE вендором были такими же проприетарными, если не более.

Недавно я провел серьезное преобразование, связанное с переносом нескольких Java-приложений из JBoss в Weblogic. Все приложения Spring/Hibernate портированы с нулевыми модификациями, потому что в них есть все необходимые библиотеки. Все приложения, использующие JPA, EJB и JSF, были бедствием для переноса. Незначительные различия в интерпретациях JPA, EJB и JSF между серверами приложений вызывали всевозможные неприятные ошибки, на исправление которых уходило вечно. Даже такие простые вещи, как именование JNDI, в AppServers были совершенно другими.

Весна - это реализация. JavaEE - это спецификация. Это огромная разница. Я бы предпочел использовать спецификацию, ЕСЛИ спецификация была на 100% герметичной и не давала места для маневра в том, как поставщики реализуют эту спецификацию. Но спецификация JavaEE никогда не была такой. Может быть, JavaEE6 более герметичен? Я не знаю. Чем больше вы можете упаковать в свою WAR, и чем меньше вы зависите от библиотек AppServer, тем более портативным будет ваше приложение, и это, в конце концов, причина, по которой я использую Java, а не Dot-NET.

Даже если бы спецификация была герметичной, было бы неплохо иметь возможность обновить сервер приложений без необходимости обновления всех моих технологических стеков во всех моих приложениях вместе с ним. Если я хочу обновить JBoss 4.2 до JBoss 7.0, я должен учитывать влияние новой версии JSF на все мои приложения. Мне не нужно учитывать влияние на мои приложения Spring-MVC (или Struts).

Это не важно Java EE 6 достаточно хорош, и из-за имеющихся там профилей он не "тяжелый" - вы просто будете использовать веб-профиль.

Лично я предпочитаю весну. Но у меня заканчиваются рациональные аргументы против Java EE 6:)

(Как мне напомнил комментарий - вы можете попробовать RichFaces, а также ICEfaces и / или PrimeFaces - в зависимости от того, какие компоненты вам нужны).

Недавно одно из моих назначений клиентов было связано с оценкой стека Spring Stack и пользовательской платформы на основе стандартов Java EE. После месяца оценки и создания прототипов я был не просто счастлив, а просто потрясен набором функций Java EE 6. Для любой новой "корпоративной" архитектуры проекта в 2011 году и в будущем я бы выбрал Java EE 6 и потенциальные расширения, такие как Seam 3 или будущий проект расширений Apache JSR299. Архитектура Java EE 6 оптимизирована и включает в себя лучшие из многих идей с открытым исходным кодом, которые развивались в последние несколько лет.

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

Большинство моих результатов опубликованы в моем блоге с объяснением ключевых концепций Java EE 6, которые могут оказаться полезными.

Конечно, не существует жесткого и быстрого правила выбора рамок. Java EE 6 мог бы быть раздутым для более простых "веб-сайтов", которые не требуют богатого состояния сеанса разговора. Вы также можете выбрать Grails или Play! Фреймворк. Но для диалоговых веб-приложений я не вижу лучшего аргумента, почему Java EE 6 не подходит.

Теперь, через некоторое время, у меня есть опыт работы со стеками:

  • Java EE 5 + Шов + GraniteDS + Flex
  • Весна 3 + Ваадин (на GWT)
  • Spring 3 + JSF 2.0 (PrimeFaces)

Мои сговоры:

  • Spring 3 намного проще, чем Seam (почти Java EE 6) и работает на Tomcat и Jetty! (Пристанище для разработки с плагином Maven - трагедия).
  • Мне нравится Flex (я действительно долгое время был разработчиком Flex, поэтому я предвзят), и если вам нужен богатый интерфейс и вы можете купить FlashBuilder, используйте его, но используйте этот бэкэнд Spring + GraniteDS или BlazeDs. Если вы не можете купить FlashBuilder, не тратьте свое время.
  • Ваадин великолепен! Процесс разработки проще, чем Flex, но вы можете легко создать многофункциональное приложение без HTML-беспорядка. Вы не будете писать одну строчку JS. Вам просто нужно немного CSS (во Flex это тоже нужно). Поэтому, если интерфейс вашего приложения будет вести себя как настольное приложение, и вы не можете (или не хотите) использовать Flex - используйте Vaadin. Предупреждение! Vaadin имеет большие JS для браузера.
  • Если вы создаете более простое приложение, похожее на веб-сайт, используйте JSF2.0 (с пружинным бэкэндом, как описано выше). Вам нужно будет бороться с HTML (я ненавижу это), и создать богатый интерфейс будет сложнее, чем Vaadin (особенно макеты). Вы получите легкий HTML для более медленных браузеров / компьютеров. Мне нравится PrimeFaces - это легко и хорошо задокументировано. Второе место - IceFaces
  • Если вы создаете веб-сайт (НЕ веб-приложение), на котором вам нужно поместить жизнь в HTML (вместо создания корпоративного приложения, которое подходит для браузера), используйте Wicket (если вы предпочитаете компонентный подход, настройте ориентацию) или SpringMVC (если вы предпочитаете на основе шаблонов), толкни отношение) или просто используй Play! фреймворк. Помните, что создавать богатые компоненты на основе данных будет намного сложнее, но вы будете иметь контроль над каждым тегом HTML (ваш HTML/Graphics дизайнер понравится)

Прочитайте Адама Бьена " Будущее предприятия Java... ясно" (Java EE с / без Spring и наоборот), включая комментарии, чтобы получить обе стороны медали. Я выберу Spring по нескольким причинам, и следующая - одна из них (воспроизведение одного из комментариев из поста)

"Я не уверен, о каком сервере Java EE 6 вы говорите. Имеется сертификат Glassfish и TMAX JEUS. Это займет довольно много времени (читай: лет), пока Java EE 6-совместимые версии WebSphere, WebLogic, JBoss и т. Д. Не будут запущены в производство и могут быть использованы для реальных приложений. Spring 3 просто нуждается в Java 1.5 и J2EE 1.4, поэтому его можно использовать практически во всех средах.

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

Короче говоря, я пришел к выводу, что лучший способ достичь этого - использовать реализации спецификаций Sun с открытым исходным кодом вплоть до необработанной JVM.

Apache Jakarta продемонстрировал поддержку своих библиотек с открытым исходным кодом, и в последнее время Sun проделала большую работу по созданию высококачественных реализаций для Glassfish v3. В любом случае, у нас также есть источник для всех модулей, поэтому, если все остальное не работает, мы можем поддерживать их самостоятельно.

Спецификации Sun обычно очень строгие, что означает, что реализации, соответствующие спецификации, могут быть легко заменены. Просто посмотрите на контейнеры сервлетов.

В этом конкретном случае я бы посоветовал взглянуть на JavaServer Faces просто потому, что он является частью Java EE 6, что означает, что он будет доступен и поддерживается в течение очень и очень долгого времени. Затем мы решили дополнить MyFaces Tomahawk, так как он дает некоторые полезные дополнения, и это проект в Джакарте.

Там нет ничего плохого с JBoss Seam или других. Просто они меньше обращают внимание на проблему обслуживания, которая так важна для нас.

Я могу видеть использование Spring, если он у вас уже есть, но какой смысл в новом проекте? Я бы пошел прямо с Java EE 6 (ejb3, jsf2.0 и т. Д.)

Если с клиентом все в порядке с Flex, сделайте это. Используйте BlazeDS или аналогичный - нет MVC. Вы можете потратить больше времени на эту часть (обмен данными между сервером и клиентом), но у вас есть полный контроль с обеих сторон.

Не используйте Vaadin, если вы не хотите убить свой браузер. Кроме того, вы тратите больше времени на обход кода, когда ваши страницы становятся более сложными. Кроме того, ваше мышление должно быть полностью изменено, и все, что вы знаете о разработке стандартного интерфейса, будет напрасным. Аргумент, что вам не нужно использовать HTML или JS, не имеет большого смысла. Вы все еще должны знать это, даже если вы не используете это. Рендеринг в HTML и JS в конце концов. Затем попробуйте отладить его - убедитесь, что у вас есть несколько дней для простых вещей. Кроме того, я не могу представить веб-разработчика, который не знает html/js.

Я просто не понимаю, почему люди пробуют все эти абстракции вместо прямого использования Java EE.

Почему до сих пор звучат слухи о том, что EJB в супертяжелом весе в 2010 году? Кажется, что люди не обновляются в технологиях Java EE. Просто попробуйте, вы будете приятно удивлены, как все упростится в Java EE 6.

Ответ на ваши вопросы зависит от требований вашего проекта. Если вам не требуются такие функции Java EE, как очереди сообщений, глобальные транзакции, управляемые контейнером, и т. Д., Используйте tomcat + spring.

Также из своего опыта я обнаружил, что проекты, которые требуют большой интеграции веб-сервисов, планирования, очередей сообщений, лучше всего выполнять с использованием некоторого стека Java EE. Хорошо, что с помощью Spring вы можете интегрировать модули Java EE, работающие на сервере приложений.

Java EE 6 очень отличается от предыдущих выпусков, и это действительно делает все намного проще. Java EE 6 объединяет лучшие идеи из разнообразного сообщества Java - например, Род Джонсон из Spring Framework активно участвовал в создании Dependency Injection JSR в Java EE 6. Преимущество использования Java EE 6 заключается в том, что вы кодируете согласно стандарт, который может быть важен в некоторых организациях для поддержки поставщиков и т. д.

GlassFish v3 поддерживает Java EE 6, он довольно легкий и запускается очень быстро. Я использовал glassfish v3 для своих разработок, и его очень легко настроить. Он поставляется с очень удобной консолью администратора, которая позволяет графически администрировать ваш сервер.

Если вы используете GlassfishV3 и JSF 2, то вы можете воспользоваться преимуществами CDI в Java EE 6, которые позволяют легко создавать диалоги (например, страницы типа мастера) в JSF.

Сказав это, использование Java EE 6 также требует от вас изучения нового API. В зависимости от имеющихся сроков, это может быть не лучшим выбором для вас. Tomcat существует уже много лет, и комбинация tomcat + spring была принята многими веб-проектами, что означает, что существует множество документации / форумов.

Если вам нужен полный стек Java EE, я рекомендую вам GlassFish 3.1. Он запускается очень быстро по сравнению с другими контейнерами Java EE, в которых реализована некоторая часть или вся Java EE 6 (JBoss 6, WebLogic 10.3.4), повторное развертывание занимает несколько секунд, и почти все может быть выполнено в соответствии с соглашением о конфигурации, это очень удобно.

Если вы хотите что-то "Легкое", вы можете настроить Apache Tomcat 7.x с желаемыми функциями. Я много использовал со следующими библиотеками: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - только ресурсы локальных транзакций JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Будучи разработчиком Java EE в течение последних 10 лет (я страдаю от ранних разработок EJB, JSF и веб-технологий), Java EE 6 очень проста, хорошо соединена, и современное оборудование работает гладко, поэтому первоначальные причины, по которым мотивирован Spring, больше не действительны.

Я работал как в Spring, так и в Java EE 6. Из своего опыта я могу сказать, что если вы выбираете старый JSP или проприетарный Flex, то вы в безопасности, если останетесь в Spring.

Но если вы хотите двигаться вперед с JSF, то пришло время перейти к Java EE 6. С Java EE 6 вы переходите к Facelets и стандартизированным библиотекам скриптов и библиотекам компонентов. Нет больше несовместимости скриптов и матриц библиотеки компонентов.

Что касается Spring MVC, это хорошо, если ваш проект не становится слишком большим. Если это огромное корпоративное приложение, придерживайтесь Java EE 6. Потому что это единственный способ упорядоченно поддерживать собственные библиотеки компонентов и пакеты ресурсов.

Я бы все еще предпочел весну.

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

Не прочитал все, но просто чтобы сказать, что теперь вы можете использовать EJB3 в войне с Java EE 6, чтобы вы могли использовать EJB3 на Tomcat (я думаю).

Я бы порекомендовал Spring + Tomcat, если вы не можете подождать, пока Glassfish v3 и Weld станут более зрелыми. В настоящее время есть несколько проблем с потреблением памяти / загрузкой процессора при запуске glassfish с приложениями с поддержкой CDI.

Я рекомендовал вам Tomcat с Spring, потому что:

  1. Spring может создавать поддерживающие бины для JSP
  2. Вы будете использовать Spring для сохранения объекта через JPA

Это хороший выбор, чтобы выбрать Tomcat, потому что вам не нужно никакой тяжелой обработки

Другие вопросы по тегам