2009-10-20 2 views
62

Я просто наткнулся на следующий новый Java Web рамок: Игратьлюбой опыт работы с «Play» java web development framework?

http://www.playframework.org/

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

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

Похоже веб-разработки Java обетованной земли ...

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

+2

Похоже, что-то еще-приложение-рамки для меня. – skaffman

ответ

70

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

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

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

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

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

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

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

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

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

  6. Модель «прикладного модуля» Play звучит так же, как и «плагин» модели Grails, так что это круто.

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

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

+1

Большое спасибо за обмен опытом с граалом. Я также очень впечатлен документацией Play ... – opensas

+0

Хороший ответ, если бы это был мой вопрос, я бы назвал его правильным. – Randin

+0

После игры с игрой! в течение нескольких дней я продаюсь. Я это><близко к возвращению на Java из ruby ​​для проекта ... – jbwiv

6

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

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

+0

Интересно, можно ли использовать groovy на всем пути ... Наверное, так ... Во всяком случае, я думаю, что это может стоить того, чтобы сделать scala выстрелом ... – opensas

3

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

+0

Я думаю, что их аргумент в том, что контроллер - это просто поведение, это вообще-то нет данных, что-то вроде библиотеки функций, поэтому они не являются объектами ... но в любом случае я вижу вашу точку зрения насчет насмешек ... – opensas

28

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

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

+1

Я написал больше на эту тему: http://www.lunatech-research.com/archives/2010/03/15/play-framework-usability –

+0

+1 для обозначения «общей эстетики». – fastcodejava

9

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

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

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

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

+1

+1 на Scala. Это действительно повышает вашу производительность. – Magnus

2

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

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

+1

Это была проблема с ранним Django, но я уверен, что это будет исправлено по мере созревания структуры. Это станет главной жалобой. –

+0

Вы имеете в виду использование нескольких баз данных одновременно? – rogerdpack

+2

Просто отметим, что есть модуль воспроизведения, который позволяет использовать несколько баз данных. Вероятно, это было неверно во время ответа, но с тех пор изменилось. – Codemwnci

9

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

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

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

3

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

4

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

+0

Это приложение теперь работает с игрой 2.2.3 на сервере Windows (запрос от ИТ-администрации). – jcstritt

Смежные вопросы