Spring 3.0 против Java EE 6.0
Я столкнулся с ситуацией...
Меня попросили дать совет относительно того, какой подход выбрать с точки зрения разработки Java EE между Spring 3.0 и Java EE 6.0. Я был и остаюсь сторонником Spring 2.5 по сравнению с классической разработкой Java EE 5, особенно с JBoss, я даже перенес старые приложения в Spring и повлиял на переопределение политики разработки, включив в него специфичные для Spring API, и помог разработка стратегического плана по созданию более легких решений, таких как Spring + Tomcat, вместо более тяжелых JBoss, прямо сейчас, мы используем JBoss просто как веб-контейнер, имея то, что я называю "контейнер внутри парадокса контейнера", то есть, имея приложения Spring с большинством его API, работающих внутри JBoss, так что мы находимся в процессе перехода на tomcat.
Однако с появлением Java EE 6.0 многие функции, которые в то время делали Spring привлекательным, легким развертыванием, меньшим количеством соединений, даже некоторого рода DI и т. Д., Похоже, так или иначе имитировались. JSF 2.0, JPA 2.0, WebBeans, WebProfiles и т. Д.
Итак, вопрос идет...
С вашей точки зрения, насколько безопасно и логично продолжать инвестировать в нестандартную среду разработки Java EE, такую как Spring, с учетом новых перспектив, предлагаемых Java EE 6.0?
Можем ли мы поговорить о трех или четырех годах разработки Spring или вы порекомендуете скорейшее принятие API Java EE 6.0 и его практики?
Я буду признателен за любые идеи с этим.
4 ответа
ИМХО, решающий момент - это не одна из особенностей. В этом отношении Spring всегда будет впереди JavaEE, что естественно для OpenSource VS. Стандарт. Итак, один факт заключается в том, что вы получаете новые функции намного раньше в Spring, чем в JavaEE (например, тестирование интеграции контейнеров - это новая функция в JavaEE 6, которая была доступна в Spring целую вечность).
Самым важным моментом ИМХО является жизненный цикл администрирования и разработки. Когда вы выбираете JavaEE, вы привязываете свою модель программирования к своей инфраструктуре. Обычно поставщики серверов приложений - не самые быстрые версии нового стандарта (вините WebSphere, JBoss, что у вас). Таким образом, это означает, что мы, вероятно, не увидим готовность к производству, поскольку JavaEE 6 будет поддерживать продукты крупных производителей до конца года.
Даже если это так, вам все равно придется преодолеть препятствия, с которыми сталкиваются администрация, ИТ-отдел и управляющие бюджетом, чтобы быть готовыми перейти на эту блестящую новую версию. Исходя из этого, JavaEE 6 даже не подходит для многих магазинов. Вы можете выбрать, что вам нравится для развертывания ваших приложений? Вы хотите выбрать Glassfish для производства? Давай, попробуй. Большинство магазинов находятся не в такой "комфортной" ситуации.
Точно наоборот: весна. Отделенная модель программирования от инфраструктуры. Иди возьми текущий 3.0.x и используй @Inject, JPA 2 и т.п. на вашем Tomcat или устаревшем сервере приложений.
Если вы уже работаете в магазине Spring, зачем переключаться? Вы довольны этим, он делает то, что вы хотите, он активно развивается, вы, вероятно, не надеетесь бежать вне Tomcat в ближайшее время, если вообще когда-либо, так как Tomcat очень зрелый и работает везде. Таким образом, любое обещание переносимости, которое может предложить Java EE, находится прямо у окна.
Не вижу смысла уходить от весны.
Поскольку Уилл и Оливер уже сказали самые важные вещи, я добавлю лишь следующее: "если это работает и делает работу, то оставь это в покое!". "Новее" и "стандартизировано" не всегда равно "лучше", на самом деле это редко бывает - новые вещи неуклюжи и глючны и (что для меня самое главное) не получили широкой поддержки. Если остальная часть Java EE 6 так же "стандартизирована", как и JSF2.0 (и все Rich/Ice/Prime/WheverFaces), то поверьте, я пока придерживаюсь Spring. Многие компании по какой-то причине придерживаются немного более старых технологий (стабильность> *), Spring существует на рынке уже много лет и хорошо зарекомендовала себя.
@Edit: Специально для @ymajoros: JSF (1.x и 2.x) является ошибочным стандартом по нескольким причинам и полезен только в нескольких случаях (например, когда вы создаете небольшие, простые сайты CRUD или когда вы Вы энтузиаст Java EE):
- Создание новых компонентов - это боль в заднице. Так как это основанная на компонентах структура, я бы предположил, что она облегчит, а не сложнее. В настоящее время я предпочитаю использовать JS+Java на бэкэнд-подходе, поскольку мне проще создавать компоненты там. Единственное, что может спасти JSF, это то, что существует множество библиотек компонентов. Проблема начинается, когда они не работают, вы хотите что-то изменить или создать свой собственный компонент.
- обработка исключений - беспорядок (или что-то изменилось за последние год или два?)
- У JSF есть проблемы с состоянием: мало плохих решений, один плохой разработчик в вашем проекте и половина вашего приложения могут быть с отслеживанием состояния и сериализацией.
- часть стандарта пользовательского интерфейса не (или, по крайней мере, когда я писал этот ответ) не покрывает большинство коллекций из Java (фактически, только прилично покрытая структура данных представляла собой List).
Что касается стандарта, который вам так нравится: они наконец-то каким-то образом интегрировали JSF с JAX-RS? Потому что в прошлый раз я проверил, что эти спецификации были полностью отделены, хотя вы могли бы сделать много улучшений. Например, почему я не могу аннотировать метод с @Path в моем компоненте поддержки, чтобы он обрабатывался как запросом REST, так и запросом JSF?
Может быть, некоторые (все?) Из этих проблем теперь исправлены, но когда я написал этот ответ, их было мало среди всех плохих вещей о JSF и стандарте в целом.
В настоящее время, если я хочу создать очень маленькое и простое приложение CRUD, я использую Play 2.0 (хотя это один из огромных анти-паттернов) или что-то вроде RoR. Когда я хочу создать большое приложение "уровня предприятия", я беру инфраструктуру JS (например, ExtJS) и библиотеку компонентов JS, комбинирую ее с бэкэндом Java (и, например, Spring), и делаю все, что мне нужно, без каких-либо накладных расходов, поэтому названный стандарт принесет.
Конечно, в JEE6 есть классные части, такие как JPA2, JAX-RS2, проверка бинов не так уж и плоха. Но использование всего стандартного стека только потому, что они назвали его "стандартом" (и, как я упоминал выше, большинство спецификаций даже не синергично), по моему скромному мнению, просто неправильно.
Я думаю, вы заметили, что работа с Spring делает вас более продуктивным, чем Java EE. Я не думаю, что они когда-нибудь смогут заставить свинью (Java EE) действительно летать. Java - отличный язык / платформа, не наносите вреда Java EE. Зачем соглашаться на "своего рода инъекцию зависимости", если у вас сегодня может быть весна?