Uso de campos públicos en Play Framework 2.0

Question

En Play Framework 1.x, la convención es usar campos públicos en las clases de Java. La justificación para esto se debe a cómo funcionan los potenciadores de propiedades de Play como se describe aquí: http://www.playframework.org/documentation/1.2.4/model

En pocas palabras, los campos públicos están 'bien' porque Play genera automáticamente setters y getters en tiempo de ejecución. Eso tiene sentido para mí y hay otras preguntas que lo cubren.

Play Framework 2.0 funciona de manera muy diferente. No hay capacidad de "Simulación de propiedades". Tal vez están buscando agregar esto más tarde, pero no pude encontrar nada que sugiera esto. Sin la simulación de propiedades, la justificación original para usar todos los campos públicos ha desaparecido. Las muestras de Play Framework 2.0 todavía usan campos públicos: http://www.playframework.org/documentation/2.0/JavaEbean

¿Por qué los campos públicos todavía se recomiendan para playframework 2.0? ¿Es esto solo un hábito de los desarrolladores en la versión anterior del juego que creó las muestras o existe otra razón por la cual el uso de campos públicos todavía se recomienda en Play 2.0?

Answer 1

Buscando en la documentación: https://github.com/playframework/Play20/wiki/JavaEbean, la reproducción generar descriptores de acceso que falta para nos.

Sin embargo, son advertencias con esta técnica, la mayoría será que la instrumentación Ebean no funcionará en generar get/colocador ... y así podría ocurrir un problema (transacción, ...)

Aquí es la cita relacionada:

el juego ha sido diseñado para generar captador/definidor de forma automática, para asegurar la compatibilidad con las bibliotecas que se esperan que estén disponibles en tiempo de ejecución (ORM, DataBinder, JSON Binder, etc). Si Play detecta cualquier getter/setter escrito por el usuario en el Modelo, no generará getter/setter para evitar cualquier conflicto.

Advertencias:

(1) Debido a la mejora de clase Ebean se produce después de la compilación, no espere que getter generado por Ebean/setters estén disponibles en tiempo de compilación. Si prefiere codificar directamente con ellos, agregue el getter/setters explícitamente usted mismo, o asegúrese de que sus clases modelo se compilan antes del resto de su proyecto, por ej. poniéndolos en un subproyecto separado.

(2) La mejora del acceso directo al campo Ebean (que permite la carga diferida) solo se aplica a las clases de Java, no a Scala. Por lo tanto, el acceso directo al campo desde los archivos fuente de Scala (incluidas las plantillas estándar de Reproducción 2) no invoca la carga diferida, lo que a menudo resulta en campos de entidad vacíos (despoblados). Para garantizar que los campos se llenen, (a) cree manualmente getter/setters y llámelos en su lugar, o (b) asegúrese de que la entidad esté completa antes de acceder a los campos.

HTH

Answer 2

Supongo que es porque los campos privados con getters y setters públicos solo generan ruido de línea y no agregan ningún valor real. En Scala, los getters y setters tampoco son visibles, también se generan automáticamente. Ej .:

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

juego fue inspirado por los carriles, y Ruby también tiene una sintaxis para captadores de generación automática y definidores:

class Person 
    attr_accessor :name 
end 

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