Добрый день,


Хотел спросить у вас что вы думаете по поводу довольно таки нового mvc-фреймворка play! для java-платформ? В чем его отличие и зачем нам еще один фреймворк спросите вы.

Дело в том что на данный момент есть много всякого mvc "добра" для java, но к сожалению возможно остановится только на нескольких фреймворках данного семейства. Сразу можно отбросить такие "чудеса" как Struts 1/2 или SpringMVC, т.к. это анти-продуктивные вещи, можно даже пойти дальше и сказать что каждый раз когда вы используете такой фреймворк ваше приложение, легким движением пальцев превращается в природный резерв/заповедник различных XML-конфигурационных файлов. В результате вы проводите больше времени за написанием различных конфигурационных файлов чем за написанием кода самого приложения.

Из "достойных" нашего внимания фреймворков можно выбрать Grails и #Roo(на данный момент мало что известно). Grails недавно приобретенный spring source, mvc фраймворк для java платформ, впитывающий в себя "лучшее" из Rails, и использующий концепции - convention over configuration. Все бы ничего, не есть у Grails одна большая проблема - это язык фреймворка т.е. groovy. Я не буду здесь вдаваться в подробности данного языка, лишь замечу что на момент написания данного поста groovy был в 60 ~ 300 раз медленнее java.

Далее есть один общий недостаток Grails и #Roo и других подобный продуктов - это servlet container standards. На сегодняшний день, почти нетронутых эволюцией, своего рода динозавры. Ну здесь тоже нечего сказать - это политика. А вот на практике получается что для простейшего приложения на Grails или SpringMVC (2 таблицы, GRUD, 4 формуляра, и пара страниц со списками) вам нужно выделить как минимум 128мб памяти вашего сервера приложений, иначе вам не избежать исключений типа "нехватка памяти", ну не смешно ли это?

Теперь вернемся к Play! . Рассмотрим несколько достоинств данного продукта :

1. Забудьте о servlet container standards, это позавчерашний день, play! базируется на Apache Mina но и его можно использовать на Google App Engine.

2. 100% Java - никаких примесей groovy подобной бесовщины.

3. HTTP, the Request/Response pattern, REST - стержень фреймворка.

4. Эффективный template engine.

5. Full-stack application framework - Поддержка JDBC, JPA, Memcache, WS(JSON/XML).

6. Архитектура встраиваемых модулей (плагинов)

Это лишь часть преимуществ, я приглашаю vas получше ознакомится с play! и поделится вашим мнением по поводу данного продукта.

--
Заранее вам благодарен

BlazkowiczДетские нападки на хорошо зарекомендовавшие себя фреймверки не делают рекламе чести. Оспорить можно каждый абзац. У Struts 2 и Spring MVC есть свои проблемы, но, судя по всему Play! их никак не решает.

Детские нападки - )))))))), "хорошо зарекомендовавшие себя фреймверки" а вам не кажется что они широко использовались лишь по тому что не было более продвинутых альтернатив ? Проблема оптимального использования серверных ресурсов по вашему это детские нападки ? Проблема сложности логики /читаемости кода приложения это тоже детские нападки.

Я все понимаю вам нравится быть немного мазохистом или у вас ностальгия, ну так и продолжайте использовать struts ведь он себя хорошо зарекомендовал и изжил.

А с чего вы взяли что Play! не решает проблем таких динозавров как Struts 2 и Spring MVC ? Play! например избавляет вас от писанины кучи ненужных конфигурационных файлов, это уже большой сдвиг вперед.

Blazkowicz
В списке достоинств ничего такого что серьезно выделяло бы фреймверк на фоне майнстрима. Вывод напрашивается простой.

Дак это только некоторые детали/особенности, если хотите полный список возможностей почитайте на сайте, список там есть.

BlazkowiczПриехали. Реализацию нужно наследовать от классов фреймверка! А как же POJO??? Код становится абсолютно не реюзабельный.

Ну здесь вы заходите в более серьезные дебаты - какой подход лучше POJO или наследование от базовых классов модели. У каждого из подходов есть свои плюсы и минусы, мы выбрали второй подход, он нам показался лучше. Если для вас это минус, что же здесь ничего не поделать.

KachalovStern
Это лишь часть преимуществ, я приглашаю vas получше ознакомится с play! и поделится вашим мнением по поводу данного продукта.
- из описания не уловил какие требования к контейнеру: версия JVM, версия JSP/сервлетов, сколько надо ОП, способен ли работать на JVM со включенным SecurityManager-ом

1. версия JVM - вроде от 1.6 сейчас, раньше была 1.5
2. версия JSP/сервлетов - отсутствует, фреймворк не работает с конейнерами сервлетов
3. сколько надо ОП - последние тесты показали что хватает 30мб для среднестатистического форума, хотя все зависит от ситуации.

BlazkowiczStern
Я все понимаю вам нравится быть немного мазохистом или у вас ностальгия, ну так и продолжайте использовать struts ведь он себя хорошо зарекомендовал и изжил.

На вашу поделку обратили внимание а вы тут сразу "мазахист"... а вы, если вы автор этого чуда, не знаете и половины java best practice. Это сразу заметно.

Нет я не автор но работаю с ним, и я предположил что товарищ мазохист только лишь потому что на мой взгляд он так рьяно отвергает прогресс.

BlazkowiczStern
Ну здесь вы заходите в более серьезные дебаты - какой подход лучше POJO или наследование от базовых классов модели.
Здесь вы пытаетесь сумничать, но при этом аргументировать чем такое наследование хорошо не можете.

Я здесь не для того что бы развязывать религиозные войны, но предлагаю вам поискать вам аргументы по данному вопросу в интернете.

Blazkowicz если вы автор этого чуда, не знаете и половины java best practice. Это сразу заметно.

java best practice - приведите пример. Скажите а grails/groovy java best practice на 100% применят или все же на 1% ? А например javassist тоже на 100% ? Или log4j ? Ищите идеала, вы мечтатель сударь .

BlazkowiczПотому что POJO имеет ряд несомненных преимуществ в плане тестирования и переиспользования кода. Фреймверки проповедующие наследование давно вымерли. А вы это называете прогрессом.

Послушайте я же вам объяснил что этот топик не для этого, хотите откройте другой по данной теме. Я не назвал именно эту часть прогрессом, но и не-прогрессом она не является. А с вашим мнением по данному поводу мы ознакомились, спасибо вам.

zalexakaSternизбавляет вас от писанины кучи ненужных конфигурационных файлов При использованиии аннотаций количество таковых вами сильно преувеличено

Да вы правы - аннотации это не идеальное решение, но все же это несравненно лучше чем куча конфигурационных файлов.

BlazkowiczДальше больше: фреймверк предлагает не создавать свойства в сущностях. Ему-то всё равно. А как нам потом эти сущности в бизнес логике-то использовать?

А можно поподробнее в чем вам такой подход не нравится?

Blazkowicz
Потому что POJO имеет ряд несомненных преимуществ в плане тестирования и переиспользования кода.

Если вы дочитаете документацию до конца то поймете что подход с наследованием не обязателен, но в 90% случаев более удобен(вам наверное трудно в это поверить) и экономит время. Но ничего вам не мешает иметь классы POJO с одной стороны и DAO с другой, только вам самим нужно будет с начала "собрать" вашу модель в jar и уж потом ее использовать на стороне контроллеров все как в Spring MVC