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

Ответ 1

Мне нужно что-то светлое, поэтому нет EJB или Seam.

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

Недавно одно из моих назначений клиентов включало оценку Spring Stack Vs Custom framework stack Vs стандартов 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 не подходит.

Ответ 5

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

• Java EE 5 + Seam + GraniteDS + Flex
• Spring 3 + Ваадин (по ГВТ)
• Spring 3 + JSF 2.0 (PrimeFaces)

Мои совпадения:

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

Ответ 6

Прочитайте Adam Bien Будущее Enterprise 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, поэтому их можно легко использовать практически во всех средах

Ответ 7

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

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

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

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

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

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

Java EE 6 сильно отличается от предыдущих выпусков, и это действительно облегчает все. Java EE 6 сочетает в себе лучшие идеи из разнообразного сообщества Java - например, Rod Johnson из структуры spring активно участвовал в создании JSR 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 была принята многими веб-проектами, что означает, что вокруг документации и форумов много.

Ответ 11

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

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

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

Ответ 12

Если вам нужен полный стек 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

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

Ответ 13

Я бы предпочел Spring.

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

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