Использование открытых полей в Play Framework 2.0

Question

В Play Framework 1.x принято использовать открытые поля в классах Java. Это объясняется тем, как работают средства улучшения свойств Play, как описано здесь: http://www.playframework.org/documentation/1.2.4/model

В двух словах, с открытыми полями все в порядке, потому что Play автоматически генерирует сеттеры и геттеры во время выполнения. Это имеет смысл для меня, и есть другие вопросы, которые охватывают это.

Play Framework 2.0 работает совсем по-другому. Нет возможности «Свойства симуляции». Возможно, они собираются добавить это позже, но я не смог найти ничего, что могло бы предложить это. Без моделирования свойств первоначальное обоснование использования всех открытых полей исчезнет. В примерах Play Framework 2.0 все еще используются открытые поля: http://www.playframework.org/documentation/2.0/JavaEbean

Почему общедоступные поля все еще рекомендуются для playframework 2.0? Это просто привычка разработчиков старой версии игры, которые создавали сэмплы, или есть еще одна причина, по которой в Play 2.0 все еще рекомендуется использовать публичные поля?

Answer 1

Глядя в документацию: https://github.com/playframework/Play20/wiki/JavaEbean, Play создаст для нас недостающие средства доступа.

Несмотря на то, что они являются предостережениями с этой техникой, большинство из них будет состоять в том, что инструментарий ebean не будет работать при генерации get / setter ... и поэтому может возникнуть проблема (транзакция, ...)

Вот соответствующая цитата:

Play был разработан для автоматической генерации getter / setter, чтобы обеспечить совместимость с библиотеками, которые ожидают их доступности во время выполнения (ORM, Databinder, JSON Binder и т. Д.).Если Play обнаруживает любой пользовательский метод получения / установки в модели, он не будет генерировать метод получения / установки, чтобы избежать какого-либо конфликта.

Предостережения:

(1) Поскольку происходит улучшение класса Ebeanпосле компиляции не ожидайте, что сгенерированные Ebean геттеры / сеттеры будут доступны во время компиляции.Если вы предпочитаете кодировать их напрямую, либо добавьте getter / setters явно самостоятельно, либо убедитесь, что классы вашей модели скомпилированы до остальной части вашего проекта, например.помещая их в отдельный подпроект.

(2) Расширение прямого доступа к полям Ebean (включение отложенной загрузки) применяется только к классам Java, но не к Scala.Таким образом, прямой доступ к полям из исходных файлов Scala (включая стандартные шаблоны Play 2) не вызывает отложенной загрузки, что часто приводит к пустым (незаполненным) полям сущностей.Чтобы убедиться, что поля заполнены, либо (а) вручную создайте метод получения / установки и вызовите их вместо, либо (б) убедитесь, что объект заполнен полностью до доступа к полям.

HTH

Answer 2

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

class Person(var name: String)
val a = new Person("John Smith")
a.name = "Henry Smith"

Игра была вдохновлена ​​Rails, а в Ruby также есть синтаксис для автоматической генерации геттеров и сеттеров:

class Person
  attr_accessor :name
end

person = Person.new
person.name = "John Henry"