Java EE 6 по сравнению с [закрытым] стеком Spring 3

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

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

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

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

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

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

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

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

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

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

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

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

Что ж, Мне нравится идея запускать свой код на непатентованной платформе (Java EE), а не на фирменный контейнер (пружина). И я думаю, что 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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