Spring 3.0 vs Java EE 6.0

Ответ 1

Решающий момент IMHO - это не одна из особенностей. В этом отношении Spring всегда будет опережать JavaEE, поскольку он естественен для OpenSource VS. Стандарт. Итак, одним из фактов является то, что вы получаете новые функции намного раньше с помощью Spring, что с JavaEE (например, тестирование интеграции контейнеров является новой функцией JavaEE 6 и доступно в Spring целую вечность).

Самый важный момент IMHO - это жизненный цикл для администрирования и развития. Когда вы выбираете JavaEE, вы привязываете свою модель программирования к своей инфраструктуре. Обычно поставщики серверов приложений - это не самые быстрые версии новых стандартных версий (вините WebSphere, JBoss, что у вас есть). Таким образом, это означает, что мы, вероятно, не увидим, что производство готово, JavaEE 6 поддерживает продукты крупных поставщиков до конца года.

Даже если это так, вам все равно придется преодолеть препятствия для вашей администрации, ИТ-отдела и менеджеров по управлению бюджетом, чтобы они могли перейти на эту блестящую новую версию. Начиная с этой стороны, JavaEE 6 не является даже вариантом для многих магазинов. Вы можете выбрать, что вам нравится при развертывании ваших приложений? Вы хотите выбрать Glassfish для производства? Давай, попробуй. Большинство магазинов не в такой "удобной" ситуации.

Точно противоположное: Spring. Развязанная модель программирования из инфраструктуры. Go возьмите текущий 3.0.x и используйте @Inject, JPA 2 и т.д. На вашем Tomcat или устаревшем сервере приложений.

Ответ 2

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

Я не вижу причин переключаться с Spring.

Ответ 3

Поскольку Уилл и Оливер уже сказали самый важный материал, я добавлю только: "если он работает и выполняет свою работу, то оставьте его в покое!". "Более новые" и "стандартизированные" не всегда равны "лучше", на самом деле это редко - новые вещи неуклюжи и неэффективны и (что наиболее важно для меня) не получили широкого распространения. Если остальная часть 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 есть проблемы с чрезмерным состоянием - несколько неправильных решений, один плохой dev в вашем проекте, а половина вашего приложения может быть сдержанной и сериализованная.
• часть пользовательского интерфейса стандарта (или, по крайней мере, не была, когда я писал этот ответ) охватывают большинство коллекций из Java (фактически только прилично охватываемая структура данных была списком).

Что касается стандарта, который вы так любите: наконец-то они каким-то образом интегрировали JSF с JAX-RS? Поскольку последний я проверил, эти спецификации были полностью разделены, хотя вы могли бы сделать много улучшений. Например, почему я не могу аннотировать метод с @Path в моей поддержке bean, поэтому он будет обрабатываться запросом REST и запросом JSF?

Возможно, некоторые (все?) из этих проблем теперь исправлены, но когда я написал этот ответ, они были лишь немногими из всех плохих вещей о JSF и стандарте в целом.

В настоящее время, если я хочу создать очень маленькое, простое приложение CRUD, я иду с Play 2.0 (хотя это один огромный анти-шаблон) или что-то вроде RoR. Когда я хочу создать большое приложение уровня предприятия, я захвачу структуру JS (например, ExtJS), а библиотеку компонентов JS объединить ее с бэкэнд Java (и, например, Spring), и я делаю то, что мне нужно, без каких-либо накладных расходов этот так называемый стандарт принесет.

Конечно, есть классные части JEE6, такие как JPA2, JAX-RS2, bean проверка не так уж плоха. Но используя весь стандартный стек только потому, что они назвали его "стандартным" (и, как я уже упоминал выше, большинство спецификаций даже не синергируют), в моем очень скромном мнении, просто неправильно.

Ответ 4

Я думаю, вы заметили, что работа с Spring делает вас более продуктивным, чем Java EE. Я не думаю, что они когда-либо смогут заставить свинью (Java EE) действительно летать. Java - отличный язык/платформа, не наносите вред его Java EE. Зачем соглашаться на "какую-то инъекцию зависимостей", если у вас сегодня есть Spring?