प्ले फ्रेमवर्क 2.0

Question

प्ले फ्रेमवर्क 1.x में सार्वजनिक फ़ील्ड का उपयोग, सम्मेलन जावा कक्षाओं पर सार्वजनिक क्षेत्रों का उपयोग करना है। इसके लिए औचित्य यह है कि प्ले प्रॉपर्टी एन्हांसर्स यहां वर्णित अनुसार काम करते हैं: http://www.playframework.org/documentation/1.2.4/model

संक्षेप में, सार्वजनिक फ़ील्ड 'ठीक' हैं क्योंकि रनटाइम पर सेटर्स और गेटर्स ऑटो-जेनरेट करते हैं। यह मुझे समझ में आता है और इसमें अन्य प्रश्न भी शामिल हैं।

प्ले फ्रेमवर्क 2.0 बहुत अलग तरीके से काम करता है। कोई "गुण सिमुलेशन" क्षमता नहीं है। शायद वे इसे बाद में जोड़ने की सोच रहे हैं लेकिन मुझे इसका सुझाव देने के लिए कुछ भी नहीं मिला। गुण सिमुलेशन के बिना, सभी सार्वजनिक क्षेत्रों का उपयोग करने के लिए मूल औचित्य खत्म हो गया है। प्ले फ्रेमवर्क 2.0 नमूने अभी भी सार्वजनिक क्षेत्रों का उपयोग करते हैं हालांकि: http://www.playframework.org/documentation/2.0/JavaEbean

सार्वजनिक फ़ील्ड अभी भी playframework 2.0 के लिए क्यों अनुशंसित हैं? क्या यह सिर्फ डेवलपर्स की आदत है जिसने नमूने बनाए हैं या फिर एक और कारण है कि सार्वजनिक क्षेत्र का उपयोग अभी भी प्ले 2.0 में क्यों किया जाता है?

Answer 1

दस्तावेज में देख रहे हैं: https://github.com/playframework/Play20/wiki/JavaEbean, प्ले के लिए याद आ रही accessors उत्पन्न होगा हमें।

हालांकि वे इस तकनीक के साथ चेतावनियां हैं, ज्यादातर कि ebean उपकरण पर काम नहीं करेगा हो जाएगा उत्पन्न प्राप्त/सेटर ... और इसलिए समस्या हो सकते हैं (लेन-देन, ...)

यहाँ है संबंधित बोली:

प्ले स्वचालित रूप से गेटर/सेटर उत्पन्न करने के लिए, पुस्तकालयों कि उम्मीद उन्हें रनटाइम पर उपलब्ध होने के लिए (ORM, Databinder, JSON बाइंडर, आदि) के साथ संगतता सुनिश्चित करने के लिए डिजाइन किया गया है। यदि प्ले मॉडल में किसी भी उपयोगकर्ता द्वारा लिखित गेटर/सेटर का पता लगाता है, तो यह किसी भी संघर्ष से बचने के लिए गेटर/सेटर उत्पन्न नहीं करेगा।

चेतावनियां:

(1) क्योंकि Ebean वर्ग वृद्धि संकलन के बाद होता है, उम्मीद नहीं है Ebean-उत्पन्न गेटर/setters संकलन समय में उपलब्ध होने की। यदि आप सीधे उनके साथ कोड करना चाहते हैं, तो या तो गेटटर/सेटर्स को स्वयं स्पष्ट रूप से जोड़ें, या सुनिश्चित करें कि आपकी मॉडल कक्षाएं आपके प्रोजेक्ट के शेष से पहले संकलित की गई हैं, उदाहरण के लिए। उन्हें एक अलग सबप्रोजेक्ट में डालकर।

(2) प्रत्यक्ष ईबीन फ़ील्ड एक्सेस (आलसी लोडिंग सक्षम करने) में वृद्धि केवल जावा कक्षाओं पर लागू होती है, स्कैला के लिए नहीं। इस प्रकार, स्कैला स्रोत फ़ाइलों (मानक प्ले 2 टेम्पलेट्स सहित) से प्रत्यक्ष क्षेत्र का उपयोग आलसी लोडिंग का आह्वान नहीं करता है, जिसके परिणामस्वरूप खाली (अप्राप्य) इकाई फ़ील्ड होते हैं। यह सुनिश्चित करने के लिए कि फ़ील्ड आबादी हो जाएं, या तो (ए) मैन्युअल रूप से गेटर/सेटर्स बनाएं और उन्हें इसके बजाय कॉल करें, या (बी) सुनिश्चित करें कि फ़ील्ड तक पहुंचने से पहले इकाई पूरी तरह से आबादी में है।

एचटीएच

Answer 2

मुझे लगता है कि ऐसा इसलिए है क्योंकि सार्वजनिक गेटर्स और सेटर्स वाले निजी क्षेत्र केवल लाइन शोर उत्पन्न करते हैं और कोई वास्तविक मूल्य नहीं जोड़ते हैं। स्कैला में, गेटर्स और सेटर्स या तो दिखाई नहीं दे रहे हैं, वे भी स्वतः उत्पन्न होते हैं। पूर्व .:

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

प्ले रेल से प्रेरित था, और रूबी भी स्वत: पैदा getters और setters के लिए एक वाक्य रचना है:

class Person 
    attr_accessor :name 
end 

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