Сейчас начинаю новый проект. Приходится выбирать технологии. Мне нужно что-то легкое, поэтому никаких EJB или Seam. С другой стороны, мне нужны JPA (Hibernate или альтернатива) и JSF с IceFaces.
Считаете ли вы, что такой стек в Spring 3, развернутый на Tomcat, является хорошим выбором? Или веб-приложение Java EE 6 могло быть лучше? Боюсь, что Java EE 6 - это новая технология, еще недостаточно документированная. Tomcat кажется проще в обслуживании, чем Glassfish 3.
Каково твое мнение? Есть ли у вас опыт?
Ответы:
Не могли бы вы объяснить, что делает EJB тяжелыми после EJB3? Вы понимаете, что мы уже не в 2004 году? Я действительно хотел бы прочитать ваше определение света и ваши аргументы (и я с удовольствием обновлю свой ответ, потому что я почти уверен, что у меня есть несколько веских вещей).
Веб-профиль Java EE 6, который включает JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... идеально подойдет для этого, и вы можете использовать веб-профиль GlassFish v3 для запуска приложения, созданного с помощью веб-профиля 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 хорошо документирован. Звучит как бесплатное требование. И, хотите верьте, хотите нет, но Spring становится все сложнее, а Java EE - проще.
Вы что-то пробовали? Сталкивались ли вы с какой-либо конкретной проблемой? Опять же, это звучит как бесплатное требование.
источник
Я не использовал JavaEE6.
Однако все предыдущие версии JavaEE и EJB меня достаточно сильно избили, и я не буду доверять им, пока они не утвердятся в качестве стандарта де-факто, а не только стандарта де-юре. Прямо сейчас Spring по-прежнему является стандартом де-факто.
Обмани меня один раз, позор вам. Обмани меня дважды, позор мне. Обмани меня трижды, EJB.
Некоторые будут утверждать, что Spring проприетарный. Я бы сказал, что реализации спецификаций JavaEE производителями были такими же проприетарными, если не больше.
Недавно я претерпел серьезное преобразование, переместив несколько Java-приложений с JBoss на Weblogic. Все приложения Spring / Hibernate были перенесены без каких-либо модификаций, поскольку в них были встроены все необходимые библиотеки. Перенос всех приложений, использующих JPA, EJB и JSF, был катастрофой. Незначительные различия в интерпретации JPA, EJB и JSF между серверами приложений вызвали всевозможные неприятные ошибки, исправление которых потребовалось целую вечность. Даже такая простая вещь, как именование JNDI, совершенно различалась между серверами приложений.
Spring - это реализация. JavaEE - это спецификация. Это ОГРОМНАЯ разница. Я бы предпочел использовать спецификацию, ЕСЛИ спецификация была на 100% герметичной и не давала абсолютно никакого пространства для маневра в способе реализации этой спецификации поставщиками. Но спецификация JavaEE никогда не была такой. Может быть, JavaEE6 более герметичен? Я не знаю. Чем больше вы можете упаковать в WAR и чем меньше вы зависите от библиотек AppServer, тем более портативным будет ваше приложение, и это, в конце концов, является причиной того, что я использую Java, а не Dot-NET.
Даже ЕСЛИ бы спецификация была герметичной, было бы неплохо иметь возможность обновить сервер приложений без необходимости обновлять все мои технологические стеки во всех моих приложениях вместе с ним. Если я хочу выполнить обновление с JBoss 4.2 до JBoss 7.0, я должен учесть влияние новой версии JSF на все мои приложения. Мне не нужно учитывать влияние на мои приложения Spring-MVC (или Struts).
источник
Неважно. Java EE 6 достаточно хорош, и из-за наличия профилей он не «тяжелый» - вы просто будете использовать веб-профиль.
Лично я предпочитаю Spring. Но у меня заканчиваются рациональные аргументы против Java EE 6 :)
(Как мне напомнил комментарий - вы можете попробовать RichFaces , а также ICEfaces и / или PrimeFaces - в зависимости от того, какие компоненты вам нужны).
источник
Недавно одно из моих клиентских заданий включало оценку Spring Stack Vs Custom framework stack и Java EE Standards. После месяца оценки и создания прототипа я был не просто счастлив, но и потрясен набором функций 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 ... Ясно» (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 принимал активное участие в создании 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 была принята во многих веб-проектах, что означает, что вокруг много документации / форумов.
источник
Я работал как с Spring, так и с Java EE 6. По своему опыту могу сказать, что если вы выбираете старый JSP или проприетарный Flex, то вы в безопасности, если останетесь со Spring.
Но если вы хотите продвинуться вперед с JSF, то пора перейти на Java EE 6. С Java EE 6 вы переходите к Facelets и стандартизированным библиотекам сценариев и библиотекам компонентов. Больше никаких несовместимостей скриптов и матриц библиотек компонентов.
Что касается Spring MVC, это хорошо, если ваш проект не становится слишком большим. Если это огромное корпоративное приложение, придерживайтесь Java EE 6. Потому что это единственный способ упорядоченного обслуживания собственных библиотек компонентов и пакетов ресурсов.
источник
Если вам нужен полный стек 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, больше не актуальны.
источник
Я по-прежнему предпочитаю весну.
И я бы перешел на JSF. Я думаю, это мертвая технология. Spring MVC будет лучшей альтернативой. Как и Flex. Подумайте о первых контрактах на услуги XML, и вы сможете полностью отделить серверную часть от пользовательского интерфейса.
источник
Я бы порекомендовал Spring + Tomcat, если только вы не можете дождаться, пока Glassfish v3 и Weld станут более зрелыми. В настоящее время существует несколько проблем с потреблением памяти / загрузкой процессора при запуске Glassfish с приложениями с поддержкой CDI.
источник
Не читал все, но просто чтобы сказать, что теперь вы можете использовать EJB3 в войне против Java EE 6, чтобы вы могли использовать EJB3 на Tomcat (я думаю).
источник
Я рекомендовал вам Tomcat со Spring, потому что:
Это хороший выбор, потому что вам не нужна тяжелая обработка.
источник