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