Зараз я починаю новий проект. Я повинен вибирати технології. Мені потрібно щось легке, тому немає EJB або Шва. З іншого боку, мені потрібні JPA (Hibernate або альтернативний) та JSF з IceFaces.
Чи вважаєте ви, що такий стек на Spring 3, розгорнутий на Tomcat, є хорошим вибором? Або веб-додаток Java EE 6 може бути кращим? Я боюся, що Java EE 6 - це нова технологія, ще недостатньо документована. Здається, Tomcat простіше в обслуговуванні, ніж Glassfish 3.
Яка твоя думка? Чи є у вас досвід?
Відповіді:
Мені потрібно щось легке, тому немає EJB або Шва.
Поясніть, що робить EJB важкими з EJB3? Ви розумієте, що ми вже не в 2004 році? Я б дуже хотів прочитати ваше визначення світла та ваші аргументи (і я з задоволенням оновлю свою відповідь, бо я впевнений, що мав би сказати кілька твердих речей).
З іншого боку, мені потрібні JPA (Hibernate або альтернативний) та JSF з IceFaces.
Веб-профіль Java EE 6, який включає JSF 2.0, JPA 2.0, перевірку Bean, EJB 3.1 Lite, CDI, ... ідеально підходить для цього, і ви можете використовувати веб-профіль GlassFish v3 для запуску програми, створеної за допомогою веб-профілю 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.
Ви щось пробували? Ви стикалися з якоюсь конкретною проблемою? Знову ж таки, це звучить як безкоштовна претензія.
Я не використовував JavaEE6.
Однак усі попередні версії JavaEE та EJB мене побили досить жорстоко, що я не буду йому довіряти, поки він не затвердиться як фактичний стандарт, а не лише як стандарт де-юре. Зараз весна все ще є фактичним стандартом.
Одуріть мене один раз, сором вам. Обдури мене двічі, сором мене. Обдури мене тричі, ЕЙБ.
Деякі будуть стверджувати, що Весна є власністю. Я міг би стверджувати, що реалізації постачальника специфікацій 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 Vs Custom frame stack Vs a 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 може бути добре роздута для більш простих "веб-сайтів", які не потребують розширеного стану розмовного сеансу. Ви також можете вибрати Грааль або Грати! Рамки. Але для розмовних веб-додатків я не бачу кращого аргументу, чому Java EE 6 не підходить.
Зараз, через деякий час, я маю досвід роботи зі стеками:
Мої висновки:
Прочитайте майбутнє Адама Бієна про підприємницьку Java ... зрозуміло (Java EE з / без Spring та Vice Versa) , включаючи коментарі, щоб отримати обидві сторони медалі. Я виберу Весну з кількох причин, і наступна - одна з них (відтворення одного з коментарів до допису)
"Я не впевнений, про який сервер Java EE 6 ви говорите. Існує сертифікована Glassfish та TMAX JEUS. Це займе досить багато часу (читайте: роки), поки версії WebSphere, WebLogic, JBoss тощо, сумісні з Java EE 6, не будуть виготовлені і можуть бути використані для реального застосування. Spring 3 просто потребує Java 1.5 та J2EE 1.4, тому їх можна легко використовувати майже у всіх середовищах '
Моя думка базується на чомусь, про що не згадували інші, а саме про те, що код у моїй роботі, як правило, живе десятиліттями (буквально), а отже, те, що обслуговування є для нас дуже важливим. Обслуговування нашого власного коду та бібліотек, якими ми користуємось. Ми контролюємо наш власний код, але в наших інтересах, щоб бібліотеки, якими ми користуємось, підтримувались іншими протягом вищезазначених десятиліть чи більше.
Якщо коротко, я дійшов висновку, що найкращим способом досягти цього є використання реалізацій специфікацій Sun із відкритим кодом аж до вихідної JVM.
З реалізацій з відкритим кодом Apache Jakarta підтвердила підтримку своїх бібліотек, і нещодавно Sun зробив багато роботи з виробництва високоякісних реалізацій для Glassfish v3. У будь-якому випадку у нас також є джерело для всіх модулів, тому, якщо все інше не вдається, ми можемо підтримувати їх самі.
Технічні характеристики сонця, як правило, мають дуже суворе значення, оскільки реалізації, що відповідають специфікаціям, можуть бути легко замінені. Просто подивіться на контейнери сервлетів.
У цьому конкретному випадку я б порадив поглянути на 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.
Відповідь на ваші запитання залежить від вимог вашого проекту. Якщо вам не потрібні функції Java EE, такі як черги повідомлень, глобальні транзакції, керовані контейнером тощо, тоді використовуйте tomcat + spring.
Також з досвіду я виявив, що проекти, які вимагають великої кількості інтеграції веб-сервісів, планування, черг повідомлень, найкраще робити за допомогою деяких стеків Java EE. Хороша річ полягає в тому, що за допомогою Spring ви все ще можете інтегрувати модулі Java EE, що працюють на сервері додатків.
Java EE 6 сильно відрізняється від попередніх випусків, і насправді робить все набагато простішим. Java EE 6 поєднує в собі найкращі ідеї різноманітної спільноти Java - наприклад, Род Джонсон із Spring framework брав активну участь у створенні Injection Dependency Injection в 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 час виконання
Будучи розробником Java EE протягом останніх 10 років (я страждаю від ранніх EJB, JSF та веб-технологій), Java EE 6 дуже проста, добре поєднана, і сучасне обладнання працює без проблем, тому оригінальні причини, що мотивували Spring, більше не дійсні.
Я все-таки віддаю перевагу весні.
І я б передав JSF. Я думаю, що це мертва технологія. Весняний MVC був би кращою альтернативою. Так само як і Flex. Подумайте з точки зору контракту на перші послуги XML, і ви зможете повністю від’єднати задній кінець від інтерфейсу.
Я б порекомендував Spring + Tomcat, якщо тільки ви не почекаєте часу, коли glassfish v3 і Weld стануть більш зрілими. В даний час існує кілька проблем із споживанням пам'яті / завантаженням процесора під час запуску glassfish із програмами з підтримкою CDI.
Читав не все, а лише сказав, що тепер ви можете використовувати EJB3 всередині війни на Java EE 6, щоб ви могли використовувати EJB3 на Tomcat (я думаю).
Я рекомендував вам Tomcat з весною, тому що:
Хороший вибір - вибрати Tomcat, оскільки вам не потрібна обробка у важкій вазі