Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (1)

Лучшие ответы пользователя

Все ответы (2)
  • Выбор Java фреймворка для веб-разработки?

    malexejev
    @malexejev
    Зависит от приложения и архитектурных требований.

    Во-первых, компонентный или action-based?

    Компонентные — легко писать (i.e. «разрабатывать большие сложные гуи») но долго разрабатывать кастомные компоненты, приложение будет в среднем тяжелее (медленнее) и будет жрать больше памяти (особенно JSF имплементации с conversation state сохраненным в HttpSession) на одного юзера. Кроме того, их нередко сложно кластеризовать из-за плохого использования сессии библиотеками.
    Из компонентных: JSF (XxxFaces), Tapestry 5, GWT. Тапестри 5 не советую — имел опыт разработки большого публичного сайта на нем. Посоветовал бы попробовать GWT — слышал максимум положительных отзывов от людей, кто что-либо на нем делал. Опять-таки, лично я не советую JSF — сразу потеряете контроль за тем, что находится у вас в сессии, приложение станет «тяжелым».

    Action-based фреймворки: чуть медленнее разработка, легко сделать приложение stateless и получить простую кластеризацию, приложение получается легковесным и быстрым.
    Посоветую такие комбинации: Spring MVC + FreeMarker, Spring MVC + Velocity, Spring MVC + JSP 2 (EL-based). Слышал положительные вещи про Stripes (но он очевидно менее популярен, чем Spring MVC) и Play (всем хорош, кроме странных архитектурных закидонов — например, предлагается пихать бизнес-логику в модели, а не в выделенный сервис-леер. одно это скорее всего будет для вас критично).

    Потом, что еще надо учесть —
    1) HTML это не XML. Если движок шаблонов использует XML — это уже не очень хорошо. DOCTYPE, browser-specific комменты придется вставлять через хаки.
    2) streaming, not buffering. Правильная работа с вебом — писать в outputStream по ходу, а не копить строчку и потом выбрасывать ее целиком. Почти все компонентные фреймворки грешат лишней буферизацией, многие action-based тоже. Отсюда завышенные требования к памяти, OOME при генерации тяжелых страниц, etc.
    3) Обратите особое внимание на то, как в выбранном фреймворке сделаны Layouts — они должны быть удобные (ie. ближе к Django-style) и имплеменчены без буферинга (см. п. 2)
    4) Если ваш фреймворк диктует вам одну конкретную прошитую javascript-библиотеку — подумайте дважды. Для intranet приложения это может сработать. Для публичного — я бы взял другой фреймворк. GWT вроде используют в паблике, но я лично с ним не работал.
    5) Если к сервису понадобится REST Api, возьмите сразу фреймворк, в котором это есть, а не надейтесь на авось.

    В целом так. Дадите больше требований к приложению — могу посоветовать что-то более конкретное.
    Ответ написан
    6 комментариев