опыт с “Игрой” платформа веб-разработки Java? [закрытый]
Я запустил бы с языка, который может быть интерпретирован. Я нашел Московский ML быть довольно легким. Это - легкая реализация Стандартного ML.
7 ответов
Я согласен с Джейсоном, что Play может оказаться лучше, чем Grails. Имея за плечами четыре проекта Grails (которым предшествовали два проекта Tapestry и один проект Wicket), я серьезно смотрю на Play.
Одна из отличительных черт Grails - это то, что «все классно». То есть вы используете Groovy для написания всего (кроме HTML и CSS) - доменов, контроллеров, служб, шаблонов страниц (GSP), библиотек тегов, Hibernate API (GORM), модульных тестов (GUnit) и скриптов сборки ( ГАНТ). Вы даже можете писать сценарии оболочки на Groovy. Таким образом, возможность кодировать все аспекты приложения с использованием одного языка снова казалась давно назревшим упрощением, восходящим ко временам написания настольных приложений на одном языке, таком как C ++ или Delphi. Тем не менее, я' Мы узнали, что здесь не всем под одну гребенку.
Во-первых, поддержка Groovy в среде IDE невелика. IntelliJ справляется с этой задачей лучше всех, но, учитывая динамический характер Groovy, он может зайти так далеко. Инструменты рефакторинга не могут (не могут) уловить все, поэтому им нельзя доверять на 100%. Это означает, что вы должны быть особенно бдительными при модульном тестировании. И здесь снова, поскольку Grails так сильно полагается на динамическую «магию», которая происходит во время выполнения, модульное тестирование в Grails должно полагаться на обширный слой имитации для его эмуляции, и этот слой насмешек необычен. Третья проблема заключается в том, что большая часть так называемого кода Groovy, который вы пишете, на самом деле является кодом предметно-ориентированного языка (DSL). (Короче говоря, DSL - это сокращенный вариант Groovy, поскольку в Groovy и многие его синтаксисы являются необязательными. ) Grails использует разные DSL для различных конфигураций, сопоставления URL-адресов и т. Д., И это несовместимо. Например, то, как вы указываете настройки log4j, совсем не похоже на то, как вы указываете источники данных, и ни то, ни другое не похоже на чистую Java, на которой основан Groovy. Итак, обещание «все будет хорошо» в любом случае рушится.
В таком случае я понимаю, откуда взялась команда Play.
Возврат к обычной Java для доменов, контроллеров, служб и JUnits имеет смысл. Строгая типизация означает, что IDE может надежно помочь с интеллектом, навигацией по коду, рефакторингом и т. Д. (И, таким образом, вам не нужно платить за IntelliJ, если вы довольны Eclipse). Необходимость писать более подробный код, чтобы получить назад сильную поддержку инструментов сейчас кажется мне хорошей сделкой. Посмотрим.
Мне нравится, что я до сих пор использую Groovy в шаблонах страниц. Боюсь, что в конечном итоге я могу поместить в шаблоны больше кода, чем следовало бы.
У меня нет опыта работы с JPA, но похоже, что это довольно близко к тому, что GORM делает для меня, так что это круто.
Поддержка Spring IOC в Grails полностью прозрачна, тогда как поддержка Play кажется минимальной; однако я думаю, что IOC слишком часто используется, и я вполне готов передать код для сопоставления Spring XML в тех редких случаях, когда они мне действительно нужны. (Один из моих открытых вопросов заключается в том, что я предполагаю, что JPA поддерживает транзакции, поэтому Play не нуждается в Spring для этого, как Grails, не так ли?)
Я никогда не был поклонником Python, поэтому я съежился, когда прочитал, что Play использует Python для своих сценариев сборки. Но я согласен, что Grails ' Скрипты GANT работают довольно медленно. Кроме того, я считаю, что, хотя GANT является огромным улучшением по сравнению с XML ANT, все же трудно осмыслить концепции ANT. Скрипты Grails GANT довольно запутаны. Итак, я займусь этим непредвзято.
Модель «модуля приложения» Play звучит так же, как модель «подключаемого модуля» Grails, так что это круто.
Я очень впечатлен документацией по Play, которую я прочитал. У меня было огромное количество вопросов, но на половину из них ответили сразу.
Я вернусь позже, когда углублюсь в суть дела.
Модель «модуля приложения» Play звучит так же, как модель «подключаемого модуля» Grails, так что это круто.
Я очень впечатлен документацией по Play, которую я прочитал. У меня было огромное количество вопросов, но на половину из них ответили сразу.
Я вернусь позже, когда углублюсь в суть дела.
Модель «модуля приложения» Play звучит так же, как модель «подключаемого модуля» Grails, так что это круто.
Я очень впечатлен документацией по Play, которую я прочитал. У меня было огромное количество вопросов, но на половину из них ответили сразу.
Я отвечу позже, когда углублюсь в суть дела.
Я использовал Grails, Tapestry 4/5 и прямую Java / JSP / Spring / Hibernate.
Я думаю, что это идет в правильном направлении впервые за долгое время. Grails был действительно хорошим первым шагом, но играйте! похоже на то, что действительно могло иметь ноги. Поддержка Scala появится в версии 1.1. Если есть шанс, я могу написать свои контроллеры / домен на Clojure, я продан;)
Мне нравится внешний вид Play, но я не пробовал. При просмотре документации выделялось одно: интенсивное использование статических методов. С точки зрения модульного тестирования это всегда значительно усложняет задачу (я думаю, что это имитирует) и является отходом от подхода OO-везде в типичной разработке Java. Может быть, в этом суть, но от этого у меня немного меньше энтузиазма ...
Я пробовал Играйте, и я впечатлен: он отлично справляется с поставкой полезной модели разработки, которая намного проще, чем у большинства фреймворков. Больше всего на свете время выполнения ' Возможность в «режиме разработки» напрямую анализировать файлы .java многого стоит: простая перезагрузка веб-страницы в браузере без запуска сценария сборки или ожидания повторного развертывания стоит большой скорости разработки. Сообщения об ошибках, отображаемые в браузере, тоже действительно хороши.
Еще одна вещь, которая поразила меня, была общая эстетика: возможно, небольшая вещь, что учебное приложение действительно выглядит хорошо (как код, так и дизайн веб-страницы), но это распространяется на всю структуру, API, а также документацию.
После наставления коллеги я посмотрел на него, последовал инструкциям и меня зацепило. Получение немедленной обратной связи прямо в браузере означает, что вам не нужно использовать IDE. Мне нравится Eclipse, но давайте посмотрим правде в глаза: после того, как вы добавили некоторые дополнения, он не так стабилен, как простой текстовый редактор. На Mac с TextMate вы даже можете щелкнуть сообщение об ошибке в своем браузере, и TextMate появится с курсором на этой строке.
Тестирование в игре также хорошо выполняется: одним нажатием кнопки вы запускаете модульные тесты, функциональные тесты и Тесты на основе Selenium.
Играть увлекательна, потому что она все еще небольшая и несложная. Он использует только муравья для сборки и делает это за 25 секунд. Чтобы внести свой вклад в красивую документацию, нужно отредактировать файлы .textile и перезагрузить документы в любом игровом приложении.
Это '
Сделать ответ на вопрос безопасности пользователя частью ключа шифрования и не сохранять ответ на вопрос безопасности в виде обычного текста (вместо него хэш)
-121--1751554-Я считаю, что метод конфигурирования ожидает абсолютный путь. В любом случае, вы также можете сначала попытаться загрузить объект Properties:
Properties props = new Properties();
props.load(new FileInputStream("log4j.properties"));
PropertyConfigurator.configure(props);
Если файл свойств находится в банке, то вы можете сделать следующее:
Properties props = new Properties();
props.load(getClass().getResourceAsStream("/log4j.properties"));
PropertyConfigurator.configure(props);
Выше предполагается, что файл log4j.properties находится в корневой папке банка.
-121--1510796-Я использую Play в небольшом проекте и, похоже, именно то, о чем они говорили. Но по умолчанию в структуре должна присутствовать одна функция: возможность работы с несколькими источниками данных (например, использовать несколько схем базы данных). Это единственная отсутствующая функция, которую я нашел до сих пор.
С уважением, Уилиан.
Мне он нравится, я использую его для небольших проектов, и пока он выглядит идеальным для работы. Однако, мне очень не хватает одной вещи, которую специально оставили без внимания: разделение слоев Service/DAO/Model! В документации ясно сказано, что одна из целей Play - избежать "анемичной модели данных": http://www.playframework.org/documentation/1.0.1/model
но по моему опыту классическое разделение слоев Service/DAO/Model экономит тонны времени разработки, когда приложение нужно рефакторить! С Play вы застряли со статическими методами, которые полагаются на специфическое для Play управление транзакциями и особенности...
Тем не менее, много больших пальцев вверх за: скорость разработки, чистоту кода, и в конце концов... удовольствие!