Какой framework Вы используете Опыт выкидывания ненужных вещей на примере реального проекта

Какой framework Вы
используете
Опыт выкидывания ненужных вещей
на примере реального проекта
О чем здесь будет
рассказываться
• http://java-source.net/open-source/webframeworks - 64 фреймворка и это далеко не
все.
• Что мы действительно хотим и
действительно нужно от веб фреймоврка?
• При выборе фреймворка – что мы
«покупаем» за свои «деньги»
• Веб-ом дело не ограничивается
С чего началось
•
•
•
•
Struts
Tapestry
JSF (Icefaces, Richfaces)
Wicket
• Spring.web
• А можно и вообще без него
Чего мы хотим от web
framework-а
•
•
•
•
•
Декларативность
Code reuse
Как можно меньше писать Ява кода
Все что можно, было автоматизировано
«Что было сложно и круто» - на рынке труда фраза
«3 года опыта разработки веб приложений на JSF»
как правило ценится выше чем «5 лет разработки
высокоэффективных приложений вообще без
фреймворков».
• Идеально как в RoR – класс в нем связь с БД, там не
валидация, там часть параметров отображения и
90% приложения рисуется автоматом
Тяжелый framework
• Много обсчета на сервере
• Большая сессия пользователя
• Ограничения на структуру URL, цикл запроса/ответа и
т.п.
• Ускорение времени на разработку «типовых» страниц –
95% веб контента делаются быстро, а остальные 5%
медленно и мучительно
• Очень не просто или вообще невозможно использовать
для public internet sites
• Необходимость учить еще один/несколько
языков/синтаксисов.
• Невозможность 100% контролировать запросы к БД (мы
говорим о persistence)
Экономика интернет
сайта
Что делать если
Типичный web запрос
Что действительно
надо от фреймворка
• Чтобы он был простой
• Быстрый
• Модульный можно было легко добавлять убирать
компоненты
• Легко масштабировался по количеству
пользователей
• Чтобы все было прямолинейно и можно было
потрогать руками (надо отредактировать CSS –
берешь и редактируешь)
• Приложение легко работало в кластере
• Легко можно было настроить failover (рассказать как
это делается в tomcat/JBoss и как делается по сути)
Легкий framework
• Минимальная нагрузка на CPU сервера
• Stateless или легкая сессия
• Возможность 100% контролировать запросы
к БД
• Больше времени на разработку одной
страницы (вроде бы).
Несколько примеров
• JSF – «тяжелый» цикл запроса, проблемы с
сессионными данными – есть много
процессора и памяти – тяжело
кластеризуется.
• ZK – динамический рендеринг страницы на
сервере, проблемы с сессионными
данными, долго учиться.
• Wicket – переусложнен, много statesaving
Типичные проблемы
тяжелых фреймворков
• Переусложненный цикл обработки запроса –
значительно увеличивает нагрузку на CPU и время
отдачи страницы
• Тяжелое и плохо управляемое состояние
сессии/страницы на стороне сервера – сложно или
невозможно добавить failover & clustering
• Компонентный подход не позволяющий в точности
использовать html предоставленный web мастером –
увеличение времени на «натягивание» дизайна.
• Неоптимальное общение с БД:
– N запросов вместо одного/двух
– Невозможность контролировать точный вид запросов и как
следствие их не оптимальность.
Сервлет API v3 уже достаточно
хорош, чего в нем не хватает
• Декларативный разбор параметров запроса
• Принудительная изоляция макета страницы
и кода
• ???
• EJB3?
Вопросы
• ???