В прошлый вторник Кэмерон Маккензи написал интересную статью на TheServerSide под названием « Переход от весны к Java EE 6: эпоха фреймворков закончилась» . В этой статье Кэмерон говорит следующее:
J2EE представляет прошлое, а Java EE 6 представляет будущее. Java EE 6 обещает нам возможность выйти за рамки. Такие фреймворки, как Spring, на самом деле являются просто мостом между ошибками прошлого J2EE и успехом будущего Java EE 6. Созданы фреймворки и установлены расширения для платформы Java EE 6. Теперь пришло время начать смотреть в прошлое Spring и смотреть вперед на технологии Seam, Weld и CDI.
Затем он ссылается на статью под названием Spring to Java EE — Migration Experience , статью, написанную Линкольном Бакстером из JBoss. В этой статье Линкольн рассказывает о многих технологиях в Java EE 6, а именно о JPA, EJB, JSF, CDI и JAX-RS. Он выделяет все различные XML-файлы, о которых вам нужно знать, а также широкий спектр серверов приложений Java EE 6: JBoss AS 6 и GlassFish v3.
У меня нет проблем со статьей Линкольна, на самом деле я думаю, что она очень информативна и является лучшей из документации, которую я видел для Java EE 6.
У меня есть некоторые проблемы с заявлениями Кэмерона о том, что фреймворки — это ошибки прошлого J2EE и что Java EE 6 представляет будущее. Платформы с открытым исходным кодом сделали J2EE успешным. Struts и Hibernate появились в первые дни J2EE и существуют до сих пор. Spring появился вскоре после этого и превратился в универсальную реализацию J2EE, которую он пытался исправить. Java EE 6 может быть лучшей основой для построения, но она определенно не заменит фреймворки.
Чтобы доказать мою точку зрения, давайте начнем с рассмотрения слоя постоянства. Раньше у нас был Hibernate на основе JDBC, теперь у нас есть реализации JPA, построенные поверх JPA API. Является ли JPA заменой для всех сред персистентности? Я работал с ним и думаю, что это хороший API, но версия 2.0 недоступна в репозитории Maven, и Alfresco недавно перешла из Hibernate (который == JPA IMO) в iBATIS для лучшего контроля уровня доступа к данным и масштабируемости. Похоже, эпоха фреймворков еще не закончилась для фреймворков персистентности.
Другие области, которые охватывает Java EE 6, и я считаю, что фреймворки будут продолжать развиваться: EJB, CDI, JSF и JAX-RS. Лично у меня нет проблем с EJB 3, и я думаю, что это значительное улучшение в EJB 2.x. У меня также нет проблем с CDI, и пока он напоминает Guice для внедрения зависимостей, он работает для меня. Однако, когда вы попадаете в пространство, в котором я живу последние пару лет (общедоступные интернет-сайты с большим трафиком), EJB и такие вещи, как функция «разговора» в CDI, не очень вам выгодны. Способом масштабирования веб-приложения является максимально возможное устранение состояния и кеша, для которых Java EE не очень помогает. Фактически, чтобы отключить сеансы в сервлет-контейнере, вы должны написать фильтр следующим образом:
public class DisabledSessionFilter extends OncePerRequestFilter {
/**
* Filters requests to disable URL-based session identifiers.
*/
@Override
protected void doFilterInternal(final HttpServletRequest request,
final HttpServletResponse response,
final FilterChain chain)
throws IOException, ServletException {
HttpServletRequestWrapper wrappedRequest = new HttpServletRequestWrapper(request) {
@Override
public HttpSession getSession(final boolean create) {
if (create) {
throw new UnsupportedOperationException("Session support disabled");
}
return null;
}
@Override
public HttpSession getSession() {
throw new UnsupportedOperationException("Session support disabled");
}
};
// process next request in chain
chain.doFilter(wrappedRequest, response);
}
}
Что насчет JAX-RS? Заменяет ли это необходимость в фреймворках? Мне нравится идея иметь REST API в Java. Тем не менее, его эталонная реализация — это Джерси , который больше похож на фреймворк, чем на Java EE. Если вы решите использовать JAX-RS в своем приложении, вам все равно придется выбирать между CXF, Jersey, RESTEasy и Restlet. Я сравнил эти фреймворки в прошлом году и обнаружил, что реализации Java EE не хватает необходимых мне функций.
Наконец, давайте поговорим о моей-наименьшей фреймворк-веб-фреймворке: JSF. Основная причина, по которой я не люблю JSF, это версия 1.x. JSF 1.0 был выпущен за год до появления термина Ajax (см. График ниже). Мало того, что разработка заняла целую вечность, но и была попыткой стать структурой клиент-компонент, которая по умолчанию была очень управляемой.
Теперь, когда вышел JSF 2.0, в него интегрирован Ajax, и он позволяет вам использовать GET вместо POST-for-all. Однако единственные люди, которым нравится Ajax, интегрированный в их веб-фреймворки, — это программисты, которые боятся JavaScript (который, вероятно, не должен разрабатывать ваш пользовательский интерфейс). Кроме того, лучшей платформой разработки компонентов для Интернета является JavaScript. Я рекомендую использовать Ajax-фреймворк для ваших компонентов, если вам действительно нужен богатый пользовательский интерфейс.
Конечно, вы можете использовать подобные Tapestry и Wicket, если вам нравится веб-разработка на основе POJO, но если вы ищете разработку веб-приложения, которое легко поддерживать и понимать, есть вероятность, что вы будете намного лучше с традиционными средами MVC, такими как Spring MVC и Struts 2. Простота и популярность Rails и Grails также подчеркивают, что разработчики предпочитают эти типы веб-фреймворков.
Еще одна причина, по которой мне не нравится JSF: очень немногие разработчики довольны этим. Основными промоутерами JSF являются авторы книг, тренеры, разработчики Java EE и разработчики MyFaces. Всякий раз, когда я выступаю на конференциях, я прошу людей поднять руки на различные веб-фреймворки, которые они используют. Я всегда прошу пользователей JSF держать руки, если им это нравится. Редко они не ложатся спать.
Похоже, нам все еще нужны веб-фреймворки.
У Эберхарда Вольфа есть интересный пост, в котором он защищает Spring и рассказывает о сравнении производительности между Spring и Java EE. Он рекомендует использовать Grails или Spring Roo, если вы хотите уровень производительности, который обеспечивает Ruby on Rails. Это правильная рекомендация, если вы создаете веб-приложения на основе CRUD, но я давно их не разрабатывал. В настоящее время разрабатываемые мною приложения являются настоящими приложениями SOFEA, где бэкэнд обслуживает XML или JSON, а клиент внешнего интерфейса — проигрыватели HTML / JavaScript / CSS, Android, iPad или Sony Blu-Ray. В моем текущем проекте наши сервисы даже не общаются с базой данных, они общаются с CMS через API RESTful. Для этого мы используем RestTemplate Spring и HttpClient, когда в нем нет нужных нам функций. Не так много в Java EE 6 для этого типа связи. Конечно,Джерси имеет клиента, но это, конечно, не часть спецификации Java EE.
Что касается нулевой производительности Ruby on Rails, мне не нужны Grails или Spring Roo, я просто использую IDEA и JRebel .
Заключение
Я не понимаю, как новые функции в Java EE 6 могут означать, что эпоха фреймворков закончилась. Java SE и J2EE всегда были основой для фреймворков. Функции Java EE 6 часто сами по себе являются структурами, которые можно использовать вне контейнера Java EE. Кроме того, Java EE 6 не предоставляет все функции, необходимые для создания масштабного веб-приложения сегодня. Здесь нет кэширования, нет веб-среды без сохранения состояния, которая может обслуживать JSON и HTML, и нет таких улучшений производительности, как JRebel. Кроме того, в Javaland есть реальная радость от таких языков, как Scala, Groovy и JRuby. Все эти языки имеют веб-фреймворки, которые порадовали многих разработчиков.
Вот эпоха фреймворков — пусть она будет жить до тех пор, пока JVM!
PS Если вы хотите, чтобы я говорил о веб-фреймворках на JVM, я буду выступать на конференции Colorado Springs Open Source Meetup и Devoxx 2010 в ближайшем будущем.
От http://raibledesigns.com/rd/entry/re_moving_from_spring_to