Spring 3.0 vs Java EE 6.0 [закрыто]

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

Я не вижу причин, чтобы переключиться с весны.

поскольку Уилл и Оливер уже сказали самые важные вещи, я только добавлю, что: "если это работает и делает работу, то оставьте ее в покое!". "Новее" и "стандартизировано" не всегда равно "лучше", на самом деле это редко происходит - новые вещи неуклюжи и глючны и (это самое главное для меня) не пользуются широкой поддержкой. Если остальная часть Java EE 6 так же "стандартизирована", как JSF2.0 (и все богатые/Ice/Prime/WhateverFaces), то поверьте мне, что сейчас я придерживаюсь весны. Многие компании придерживаются немного старые технологии по какой-то причине (стабильность > *), весна была на рынке в течение многих лет и хорошо зарекомендовала себя.

@Edit: Особенно для @ymajoros: JSF (оба 1.x и 2.x) является ошибочным стандартом из-за нескольких причин и полезен только в нескольких случаях (например, когда вы создаете небольшие, простые веб-сайты CRUD или когда вы энтузиаст Java EE):

• создание новых компонентов-это боль в заднице. Так как это компонент на основе структуры я бы предположил это сделал бы вещи легче не посильнее. В настоящее время я предпочитаю идти с JS + Java на бэкэнд подход, так как на самом деле мне проще создавать компоненты там. Единственная точка сохранения JSF заключается в том, что существует множество библиотек компонентов. Проблема начинается, когда они не работают, вы хотите что-то изменить или создать свой собственный компонент.
• обработка исключений-это беспорядок (или что-то изменилось в прошлом год или два?)
• JSF имеет проблемы с тем, чтобы быть слишком статусным-несколько плохих решений, один плохой dev в вашем проекте и половина вашего приложения могут быть статусными и сериализованный.
• часть пользовательского интерфейса стандарта не делает (или, по крайней мере, не сделал, когда я писал этот ответ) охватывает большинство коллекций из Java (на самом деле только прилично покрытая структура данных была списком).

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

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

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

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

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