Любой опыт работы с инфраструктурой разработки java для игры "Play"?

Я только что наткнулся на следующие новые веб-рамки java: Play

http://www.playframework.org/

http://www.playframework.org/documentation/1.0/home

с таким потрясающим списком функций, я очень удивлен, что раньше не слышал об этом...

Похоже, что веб-разработка java web обещала землю...

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

Ответ 1

Я согласен с Джейсоном в том, что Play может оказаться лучше, чем Grails. С четырьмя проектами Grails под моим поясом (впереди два проекта Tapestry и один проект Wicket), я серьезно смотрю Play Play.

Одна из вещей, которые, как я думал, была крутой в отношении Grails, это то, что "все Groovy". То есть вы используете Groovy для написания всего (кроме HTML и CSS) - доменов, контроллеров, служб, шаблонов страниц (GSP), библиотек тегов, Hibernate API (GORM), модульных тестов (GUnit) и сборки скрипты (GANT). Вы даже можете писать сценарии оболочки в Groovy. Таким образом, возможность кодировать все аспекты приложения с использованием одного языка снова казалась упрощением, которое было давно названо - вернемся к дням написания настольных приложений на одном языке, таком как С++ или Delphi. Однако я узнал, что один размер не подходит всем.

Во-первых, поддержка IDE для Groovy невелика. IntelliJ выполняет лучшую работу, но с Groovy является динамическим, он может зайти так далеко. Инструменты рефакторинга не могут (не могут) поймать все, поэтому вы не можете доверять им 100%. Это означает, что вы должны проявлять особую бдительность при модульном тестировании. Здесь снова, потому что Grails так много полагается на динамическое "волшебство", которое происходит во время выполнения, модульное тестирование в Grails должно опираться на обширный издевательский слой, чтобы подражать ему, и этот насмешливый слой является изворотливым. Третья проблема заключается в том, что большая часть так называемого Groovy кода, который вы пишете, на самом деле является кодом домена (DSL). (Короче говоря, DSL - это короткие клавиши Groovy, используя тот факт, что в Groovy и много синтаксиса является необязательным.) Grails использует разные DSL для различных конфигураций, сопоставления URL и т.д. И это непоследовательно. Например, как вы указываете параметры log4j, ничего не похоже на то, как вы указываете источники данных, и ни одна из них не выглядит как чистая Java, на которой основана Groovy. Таким образом, обещание "все Groovy" все равно падает.

В этом случае я вижу, откуда приходит команда Play.

  • Возвращение к обычной Java для доменов, контроллеров, служб и JUnits имеет смысл. Сильная типизация означает, что IDE может надежно помочь с интеллектом, навигацией кода, рефакторингом и т.д. (И, таким образом, вам не нужно платить за IntelliJ, если вы довольны Eclipse.) Необходимо написать более подробный код, чтобы получить сильную поддержку инструмента, похоже, для меня сейчас очень хорошо. Посмотрим.

  • Мне нравится, что я все еще использую Groovy в шаблонах страниц. Боюсь, что в конце концов я смогу добавить больше кода в шаблоны, чем должен.

  • У меня нет опыта работы с JPA, но похоже, что он довольно близок к тому, что делает GORM для меня, так что круто.

  • Поддержка IOC Spring в Grails полностью прозрачна, тогда как поддержка Play кажется минимальной; однако, я считаю, что IOC слишком злоупотребляет, и я совершенно готов передать код XML Spring в редкий случай, который мне действительно нужен. (Один из моих открытых вопросов заключается в том, что я предполагаю, что JPA поддерживает транзакцию, поэтому Play не нужен Spring для того, что делает Grails, нет?)

  • Я никогда не был поклонником Python, поэтому я съежился, когда прочитал, что Play использует Python для своих скриптов сборки. Но я согласен с тем, что скрипты GANT от Grails работают довольно медленно. Плюс я нахожу, что, хотя GANT является огромным улучшением по сравнению с XML ANT, все равно трудно обернуть голову концепциями ANT. Скрипты Grails GANT довольно запутаны. Итак, я пойду к нему с открытым сознанием.

  • Модель Play "application module" звучит так же, как модель плагинов Grails, так что круто.

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

Я снова расскажу о себе позже, когда я погружусь глубже.

Ответ 2

Я пробовал Play, и я впечатлен: он отлично справляется с предоставлением полезной модели разработки, которая намного проще, чем большинство фреймворков ". Более того, возможность выполнения в режиме разработки для анализа файлов .java напрямую стоит того: просто перезагрузка веб-страницы в браузере без запуска сборки script или ожидание перераспределения стоит большого объема разработки скорость. Сообщения об ошибках, отображаемые в браузере, действительно хороши.

Еще одна вещь, которая произвела на меня впечатление, была общая эстетика: возможно, очень мало того, что учебное приложение действительно выглядит хорошо (как код, так и дизайн веб-страницы), но это распространяется на всю структуру, API, а также документация.

Ответ 3

После подталкивания коллеги я посмотрел на него, последовал за учебником и зацепился. Получение немедленной обратной связи прямо в вашем браузере означает, что вам не нужно использовать среду IDE. Я люблю Eclipse, но позвольте ему взглянуть: после того, как вы добавили некоторые дополнительные функции, это не так стабильно, как простой текстовый редактор. На Mac с TextMate вы можете даже щелкнуть по сообщению об ошибке в своем браузере, а TextMate появится с курсором на этой строке.

Тестирование в игре также хорошо сделано, с помощью одной кнопки вы запускаете модульные тесты, функциональные тесты и тесты на основе селена.

Игра увлекательна, потому что она все еще маленькая и несложная. Он использует только ant для сборки и делает это за 25 секунд. Внести вклад в красивую документацию - это отредактировать файлы .textile и перезагрузить документы в любом игровом приложении.

То, как я попал в квест, чтобы перевести учебник на использование Scala, добавив поддержку Scala, где это необходимо, чтобы сделать его как можно более приятным.

Ответ 4

Мне нравится, я использую его для небольших проектов, и пока он отлично подходит для работы. Тем не менее, есть одна вещь, которую я очень скучаю, потому что это было сделано специально: Разделение сервисов /DAO/Model! Документация гласит, что одна из целей игры - избежать "модели анемичных данных": http://www.playframework.org/documentation/1.0.1/model

но по моему опыту классическое разделение слоев Service/DAO/Model экономит массу времени разработки, когда приложение необходимо реорганизовать! В Play вы застряли в статических методах, которые зависят от управления транзакциями, специфичных для конкретной игры, и особенностей...

Однако многие большие пальцы вверх: скорость разработки, чистота кода и, в конце концов, удовольствие!

Ответ 5

Я использовал Grails, Tapestry 4/5 и прямой Java/JSP/ Spring/Hibernate.

Я думаю, что это происходит в правильном направлении впервые за долгое время. Grails был действительно хорошим первым шагом, но Play! похоже, что-то, что действительно может иметь ноги. Поддержка Scala в 1.1. Если есть вероятность, что я могу написать мои контроллеры/домен в Clojure, я продаюсь;)

Ответ 6

Начиная с года и без видимых ошибок после 18 небольших выпусков мы используем Play! 1.2.4 в производственной "отсутствующей" заявке на интранет для школы (актеры: > 100 учителей, 700 студентов, административная группа). Клиентская сторона написана с помощью FLEX 4.6 от Adobe (очень красивые виды). Данные отправляются и принимаются в формате AMF3 (Cinnamon module). Мы используем собственный простой уровень dao на основе JPA EclipseLink и MySql для БД. Приложение хранится на виртуальном сервере Linux. Я очень поклонник Play для своей простоты и очень продуктивного подхода.

Ответ 7

Мне нравится внешний вид Play, но не пробовал. Из сканирования документов, которые выделялись, было тяжелое использование статических методов. С точки зрения модульной проверки это всегда делает вещи намного сложнее (я думаю, насмехается), и это отход от подхода OO-везде в типичной разработке Java. Может быть, это и есть точка, но это просто то, что сделало меня немного менее восторженным...

Ответ 8

В настоящее время я создаю веб-приложения на работе, используя платформу воспроизведения, которая делает массивную обработку данных. Я должен сказать, что скорость, которую играют в одиночку, значительна и больше, чем может предоставить RoR. Кроме того, игра представляет собой основанную на Java платформу, и, следовательно, многопоточность может быть легко выполнена. Далее вы сможете получить максимальную производительность, когда используете java-модули, такие как Japid и Netty, вместе с play.It, как бесконечное количество настроек может быть сделано для производительности. По-моему, надо попробовать.

Ответ 9

Я использую Play в небольшом проекте, и, похоже, это именно то, о чем они говорили. Но одна функция, которую я думаю, должна присутствовать по умолчанию в рамках: возможность работать с несколькими источниками данных (например, использовать более одной схемы базы данных). Это единственная пропавшая функция, которую я нашел до сих пор.

С уважением, Uilian.