In Play Framework 1.x besteht die Konvention darin, öffentliche Felder für Java-Klassen zu verwenden. Der Grund dafür ist, dass die Play Properties Enhancer wie hier beschrieben funktionieren: Ссылка
Kurz gesagt, öffentliche Felder sind "ok", da Play zur Laufzeit Setter und Getter automatisch generiert. Das macht Sinn für mich und es gibt andere Fragen, die das abdecken.
Play Framework 2.0 funktioniert sehr unterschiedlich. Es gibt keine "Eigenschaften Simulation" -Fähigkeit. Vielleicht versuchen sie später, das hinzuzufügen, aber ich konnte nichts finden, was das vermuten lässt. Ohne die Simulation der Eigenschaften ist die ursprüngliche Begründung für die Verwendung aller öffentlichen Felder weg. Die Play Framework 2.0-Beispiele verwenden jedoch weiterhin öffentliche Felder: Ссылка
Warum werden öffentliche Felder für playframework 2.0 immer noch empfohlen? Ist das nur eine Gewohnheit der Entwickler auf der alten Version von play, die die Samples erstellt hat oder gibt es einen weiteren Grund, warum die Verwendung von öffentlichen Feldern in Play 2.0 immer noch empfohlen wird?
Wenn Sie in der Dokumentation Ссылка nachschauen, erzeugt Play fehlende Accessoren für uns.
Allerdings sind sie Vorbehalte mit dieser Technik, die meisten werden sein, dass die Ebean-Instrumentierung nicht mit generate get / setter arbeiten wird ... und so könnte ein Problem auftreten (Transaktion, ...)
Hier ist das verwandte Zitat:
Play wurde entwickelt, um Getter / Setter automatisch zu generieren, um Kompatibilität mit Bibliotheken zu gewährleisten, die erwarten, dass sie zur Laufzeit verfügbar sind (ORM, Databinder, JSON Binder, usw.). Wenn Play einen benutzerdefinierten Getter / Setter im Modell erkennt, wird kein Getter / Setter generiert, um Konflikte zu vermeiden.
Vorbehalte:
(1) Da die Ebean-Klassenerweiterung nach der Kompilierung erfolgt, erwarten Sie nicht, dass Ebean-generierte Getter / Setter zur Kompilierungszeit verfügbar sind. Wenn Sie lieber direkt mit ihnen codieren möchten, fügen Sie die Getter / Setter entweder explizit hinzu oder stellen Sie sicher, dass Ihre Modellklassen vor dem Rest Ihres Projekts kompiliert werden, z. indem Sie sie in ein separates Teilprojekt einfügen.
(2) Die Erweiterung des direkten Ebean-Feldzugriffs (Lazy-Laden aktivieren) wird nur auf Java-Klassen und nicht auf Scala angewendet. Daher ruft der direkte Feldzugriff von Scala-Quelldateien (einschließlich Standard-Play-2-Vorlagen) kein verzögertes Laden auf, was häufig zu leeren (nicht aufgefüllten) Entitätsfeldern führt. Um sicherzustellen, dass die Felder ausgefüllt werden, erstellen Sie entweder (manuell) Getter / Setter und rufen Sie sie stattdessen auf oder (b) stellen Sie sicher, dass die Entität vollständig ausgefüllt ist, bevor Sie auf die Felder zugreifen.
HTH
Ich schätze, das liegt daran, dass private Felder mit öffentlichen Gettern und Settern nur Linienrauschen erzeugen und keinen wirklichen Wert hinzufügen. In Scala sind Getter und Setter nicht sichtbar, sie werden ebenfalls automatisch generiert. Bsp .:
%Vor%Play wurde von Rails inspiriert, und Ruby hat auch eine Syntax zum automatischen Generieren von Getter und Setter:
%Vor%Tags und Links java playframework-2.0 javabeans