JSF बैकिंग बीन संरचना (सर्वोत्तम अभ्यास)

Question

मुझे उम्मीद है कि इस पोस्ट में, मैं JSF पृष्ठों और बैकिंग बीन्स के बीच इंटरफेस के लिए सर्वोत्तम प्रथाओं पर लोगों की राय प्राप्त कर सकता हूं।

एक चीज जो मैं कभी नहीं सुलझा सकता, वह है मेरी बैकिंग बीन्स की संरचना। इसके अलावा, मुझे इस विषय पर एक अच्छा लेख नहीं मिला।

किस गुणों का संबंध बैकिंग बीन्स से है? जब एक नई बीन बनाने और उस पर गुण जोड़ने का विरोध करने के लिए किसी दिए गए बीन में अधिक गुण जोड़ना उचित है? सरल अनुप्रयोगों के लिए, क्या यह समझ में आता है कि पूरे पृष्ठ के लिए केवल एक ही बैकिंग बीन है, एक बीन को दूसरे में इंजेक्ट करने के साथ शामिल जटिलता को देखते हुए? क्या बैकिंग बीन में कोई वास्तविक व्यावसायिक तर्क होना चाहिए, या इसमें कड़ाई से डेटा होना चाहिए?

बेझिझक इन सवालों के जवाब दें और जो भी सामने आएं।

---

जेएसएफ पेज और बैकिंग बीन के बीच युग्मन को कम करने के लिए, मैं कभी भी जेएसएफ पेज को किसी भी बैकिंग बीन संपत्ति की संपत्तियों तक पहुंचने की अनुमति नहीं देता। उदाहरण के लिए, मैं कभी इस तरह की अनुमति नहीं देता:

<h:outputText value="#{myBean.anObject.anObjectProperty}" />

मुझे हमेशा कुछ ऐसा चाहिए होता है:

<h:outputText value="#{myBean.theObjectProperty}" />

के समर्थन मूल्य के साथ:

public String getTheObjectProperty()
{
    return anObject.getAnObjectProperty();
}

जब मैं किसी संग्रह पर लूप करता हूं, तो मैं उदाहरण के लिए, डेटा टेबल में किसी ऑब्जेक्ट में ड्रिलिंग से बचने के लिए एक रैपर क्लास का उपयोग करता हूं।

सामान्य तौर पर, यह दृष्टिकोण मुझे "सही" लगता है। यह दृश्य और डेटा के बीच किसी भी युग्मन से बचा जाता है। कृपया मुझे सुधारें अगर मैं गलत हूं।

Comments

क्या आप इसके लिए एक उदाहरण दे सकते हैं: जब मैं किसी संग्रह पर लूप करता हूं, तो मैं उदाहरण के लिए, डेटा तालिका में किसी ऑब्जेक्ट में ड्रिलिंग से बचने के लिए एक रैपर क्लास का उपयोग करता हूं।

— कोरे तुगे

अधिक जानकारी के लिए, पर BalusC का जवाब देखने के stackoverflow.com/questions/7223055/...

— जैक Marrapese

Answer 1

आप इसे देखना चाहते हैं: विभिन्न प्रकार के JSF प्रबंधित बीन्स के बीच अंतर करना ।

यहाँ विभिन्न बीन प्रकारों का वर्णन है, जैसा कि नील ग्रिफिन के उपरोक्त लेख में परिभाषित किया गया है:

• मॉडल प्रबंधित-बीन : सामान्य रूप से सत्र गुंजाइश। इस प्रकार के प्रबंधित-बीन MVC डिजाइन पैटर्न के "मॉडल" चिंता में भाग लेते हैं। जब आप "मॉडल" शब्द देखते हैं - तो सोचो। जेएसएफ मॉडल-बीन एक पीओजेओ होना चाहिए जो कि गेटबैन डिजाइन पैटर्न का अनुसरण करता है जिसमें गेटर्स / एन्कैप्सुलेटिंग गुण होते हैं। एक मॉडल बीन के लिए सबसे आम उपयोग मामला डेटाबेस इकाई होना है, या बस डेटाबेस क्वेरी के परिणाम सेट से पंक्तियों के एक सेट का प्रतिनिधित्व करना है।
• बैकिंग मैनेज्ड-बीन : सामान्य रूप से अनुरोध स्कोप। इस प्रकार के प्रबंधित-बीन MVC डिजाइन पैटर्न के "व्यू" चिंता में भाग लेते हैं। बैकिंग-बीन का उद्देश्य यूआई तर्क का समर्थन करना है, और जेएसएफ दृश्य के साथ 1 :: 1 संबंध, या फेसलेट रचना में जेएसएफ फॉर्म है। हालाँकि इसमें आमतौर पर संबंधित गेटर्स / सेटर्स के साथ जावाबैन-स्टाइल गुण होते हैं, ये अंतर्निहित अनुप्रयोग डेटा मॉडल के दृश्य के गुण हैं - नहीं। JSF बैकिंग-बीन्स में JSF एक्शन लिस्टनर और valueChangeListener विधियाँ भी हो सकती हैं।
• नियंत्रक प्रबंधित-बीन : सामान्य रूप से अनुरोध गुंजाइश है। इस प्रकार का प्रबंधित बीन MVC डिजाइन पैटर्न की "नियंत्रक" चिंता में भाग लेता है। नियंत्रक बीन का उद्देश्य कुछ प्रकार के व्यापारिक तर्क को निष्पादित करना और JSF नेविगेशन-हैंडलर के लिए एक नेविगेशन परिणाम लौटना है। JSF कंट्रोलर-बीन्स में आमतौर पर JSF एक्शन मेथड होते हैं (और एक्शन लिस्टनर तरीके नहीं)।
• प्रबंधित प्रबंधित-बीन : सामान्य रूप से सत्र या एप्लिकेशन स्कोप। इस प्रकार की बीन MVC डिजाइन पैटर्न के "व्यू" चिंता में एक या अधिक विचारों का "समर्थन" करती है। विशिष्ट उपयोग का मामला JSF h के लिए एक ArrayList की आपूर्ति कर रहा है: selectOneMenu ड्रॉप-डाउन सूचियाँ जो एक से अधिक JSF दृश्य में दिखाई देती हैं। यदि ड्रॉपडाउन सूचियों में डेटा उपयोगकर्ता के लिए विशेष रूप से है, तो सेम को सत्र के दायरे में रखा जाएगा। हालांकि, यदि डेटा सभी उपयोगकर्ताओं (जैसे प्रांतों की एक ड्रॉपडाउन सूची) पर लागू होता है, तो सेम को आवेदन के दायरे में रखा जाएगा, ताकि इसे सभी उपयोगकर्ताओं के लिए कैश किया जा सके।
• उपयोगिता प्रबंधित-बीन : सामान्य रूप से अनुप्रयोग गुंजाइश। इस प्रकार की बीन एक या एक से अधिक JSF विचारों को "उपयोगिता" फ़ंक्शन प्रदान करती है। इसका एक अच्छा उदाहरण एक फाइलअप लोड हो सकता है जिसका उपयोग कई वेब अनुप्रयोगों में किया जा सकता है।

Comments

यह बढ़िया लेख है। मैंने इसे पहले कभी नहीं देखा है और निश्चित रूप से खुशी है कि आपने इसे पोस्ट किया है। जिसने भी इसे वोट किया है वह पागल है। यह विशिष्ट नहीं है।

— जैक मर्रेपी

वास्तविक लेख के लिए लिंक चला गया प्रतीत होता है।

— बिल रोसमस

एक प्रति यहां

— ChrLipp

फिर भी, मैं यह नहीं समझ सकता कि यह उत्तर वर्तमान में 71 अपवोट्स पर है। जिसने भी उन नियमों के अनुसार अपने JSF आवेदन को लागू किया है, निस्संदेह JSF पर बहुत अपारदर्शी ढाँचा और उनके JSF अनुप्रयोगों को एक बड़ा कोड गड़बड़ होने के कारण पराजित होना चाहिए और वे सभी गलत पाठ और तथाकथित के आधार पर अपने स्वयं के बुरे के बजाय JSF को ही दोषी मानते हैं "सर्वोत्तम अभ्यास" सीखा।

— बालूसी

क्या इन बीन्स के किसी भी तर्क को सर्वर के बजाय ब्राउज़र में निष्पादित किया गया है?

— एस्क्लेरा

Answer 2

बड़ा सवाल है। जेएसएफ में स्थानांतरित होने पर मुझे उसी दुविधा का सामना करना पड़ा। यह वास्तव में आपके आवेदन पर निर्भर करता है। मैं जावा ईई दुनिया से हूं इसलिए मैं आपकी बैकिंग बीन्स में कम से कम व्यावसायिक तर्क रखने की सलाह दूंगा। यदि तर्क शुद्ध रूप से आपके पृष्ठ की प्रस्तुति से संबंधित है, तो यह बैकिंग बीन में होना ठीक है।

मेरा मानना ​​है कि JSF की एक (कई) ताकत वास्तव में तथ्य यह है कि आप डोमेन ऑब्जेक्ट्स को सीधे प्रबंधित सेम पर उजागर कर सकते हैं। इसलिए मैं दृढ़ता से <:outputText value="#{myBean.anObject.anObjectProperty}" />दृष्टिकोण की सिफारिश करूंगा , अन्यथा आप प्रत्येक संपत्ति को मैन्युअल रूप से उजागर करने के लिए खुद के लिए बहुत अधिक काम करते हैं। इसके अलावा जब आप सभी संपत्तियों को इनकैप्सुलेट करते हैं तो डेटा डालने या अपडेट करने में थोड़ी गड़बड़ होगी। ऐसी परिस्थितियाँ हैं जहाँ एक एकल डोमेन ऑब्जेक्ट पर्याप्त नहीं हो सकता है। उन मामलों में मैं बीन पर इसे उजागर करने से पहले एक ValueObject तैयार करता हूं ।

संपादित करें: वास्तव में, यदि आप हर उस वस्तु संपत्ति का एनकाउंटर करने जा रहे हैं जिसे आप उजागर करना चाहते हैं, तो मैं आपको सलाह दूंगा कि आप यूआई घटकों को बैकिंग बीन से बांधें और फिर सामग्री को सीधे घटक के मूल्य में इंजेक्ट करें।

बीन संरचना के संदर्भ में मेरे लिए मोड़ तब था जब मैंने वेब अनुप्रयोगों के निर्माण के बारे में मेरे द्वारा ज्ञात सभी सामग्रियों को बलपूर्वक अनदेखा कर दिया और इसके बजाय जीयूआई अनुप्रयोग के रूप में व्यवहार करना शुरू कर दिया। JSF ने बहुत सारी स्विंग की नकल की और इसलिए स्विंग अनुप्रयोगों को विकसित करने के लिए सबसे अच्छा अभ्यास ज्यादातर JSF अनुप्रयोगों के निर्माण पर लागू होगा।

Comments

आपकी अंतर्दृष्टि के लिए धन्यवाद। मैंने कभी भी स्विंग एप्लिकेशन (एक लंबे समय से पहले अकादमिक परियोजनाओं के अलावा) के तरीके में बहुत कुछ नहीं किया। स्विंग एप्लिकेशन के कुछ अच्छे सिद्धांत क्या हैं? मान डालने और अपडेट करने के दौरान भी गड़बड़ी क्यों होती है? मुझे भी ऐसा ही लगता है?

— ज़ैक मैरपेज़

Answer 3

मुझे लगता है कि आपकी बैकिंग सेम के साथ सबसे महत्वपूर्ण बात उनके लॉजिक को अलग करना है। यदि आपके पास CMS सिस्टम के लिए एक फ्रंट पेज है, तो मुझे कोड के प्रत्येक टुकड़े को एक बीन में डालने के लिए बुरे अभ्यास के रूप में देखा जाएगा क्योंकि:

1. बीन अंततः बहुत बड़ी हो जाएगी
2. अन्य लोगों के लिए इसका आसान तरीका यह है कि यदि वे लॉगिन पृष्ठ का निवारण कर रहे हैं तो उनकी क्या तलाश है, अगर वे आसानी से लॉगिनबिन.जवा फ़ाइल देख सकते हैं।
3. कभी-कभी आपके पास कार्यक्षमता के छोटे टुकड़े होते हैं जो आपके बाकी कोड से स्पष्ट रूप से अलग होते हैं, इसे अलग करने से मुझे लगता है कि आप अपने आप को पुनर्विकास करना आसान बना देंगे / इस कोड को कुछ बड़े में विस्तारित कर सकते हैं, जब आपके पास पहले से ही एक अच्छा सेम है संरचना।
4. 1 बड़ा बीन होने पर, यह सब करने के लिए, यह अधिक मेमोरी निर्भर करेगा यदि आपको इस तरह की घोषणाएँ करनी हैं जैसे MyBigBean bigBean = new MyBigBean (); इसके बजाय वास्तव में लॉगिनबिन लॉगिन करके आपको आवश्यक funksjonality का उपयोग करने की जगह = नया लॉगिन (); (मुझे सही अगर Im गलत यहाँ ???)
5. मेरी राय में, अपने बीन्स को अलग करना आपके तरीकों को अलग करने जैसा है। आप 1 बड़ी विधि नहीं चाहते हैं जो 100 से अधिक लाइनों पर चलती है, बल्कि इसे नए तरीकों से विभाजित करती है जो उनके विशिष्ट कार्य को संभालती है।
6. याद रखें, सबसे अधिक संभावना है कि आपके अलावा किसी और को आपके जेएसएफ प्रोजेक्ट्स पर काम करना होगा।

---

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

इस बारे में मेरे 2 सेंट भी पहले से ही उत्तर के रूप में चिह्नित प्रश्न के साथ।

Comments

हालाँकि, यदि आपके पास एक बड़ी वस्तु है जो आपके बीन में बैठी है, और आपके पास है - कहो - 15 ईएल फ़ंक्शन जेएसएफ पृष्ठ से उस ऑब्जेक्ट में खुदाई करते हैं, तो अब आप न केवल बीन के लिए, बल्कि उस वस्तु से बंधे हैं। इसलिए यूआई को तोड़े बिना उस वस्तु को हटाना मुश्किल होगा।

— ज़ैक मार्र्पीस

लेकिन क्या आपके बैकिंग बीन को उस वस्तु से नहीं जोड़ा जाना चाहिए? और आपका UI बैकिंग बीन से बंधा है? जब आपको इसे संशोधित करना होगा, तो आपको अपने सभी गेटर्स / बसर्स को UI और बीन दोनों में बदलना होगा।

— क्रिस डेल

Answer 4

मैं आपके हर सवाल का जवाब नहीं दे सकता, क्योंकि कुछ मामले के मामले पर काफी निर्भर करते हैं।

• यह आपके बैकिंग बीन में व्यावसायिक तर्क रखने के लिए ठीक है। यह निर्भर करता है कि आप कहां से आ रहे हैं। यदि आप डोमेन संचालित डिज़ाइन का अभ्यास कर रहे हैं, तो आपको व्यापार तर्क को बैकिंग बीन में शामिल करने के लिए लुभाया जाएगा या साथ ही दृढ़ता तर्क भी हो सकता है। उनका तर्क है कि इतनी गूंगी वस्तु क्यों। वस्तु केवल राज्य नहीं बल्कि व्यवहार भी होनी चाहिए। दूसरी ओर अगर आप पारंपरिक जावा ईई चीजों को करने के तरीके पर विचार करते हैं, तो आप महसूस कर सकते हैं कि आपके बैकिंग बीन में डेटा होना चाहिए, जो आपकी इकाई बीन भी हो सकती है, और कुछ सत्र बीन या कुछ में अन्य व्यवसाय और दृढ़ता तर्क भी हो सकता है। वह भी ठीक है।

• यह पूरी तरह से ठीक है कि पूरे पृष्ठ के लिए सिंगल बैकिंग बीन है। मैं इस अकेले के साथ कोई समस्या नहीं देख रहा हूँ। यह सही नहीं लग सकता है, लेकिन यह मामले पर निर्भर करता है।

• आपके हाथ में होने वाले मामले पर आपका अन्य प्रश्न कहीं अधिक निर्भर है। मैं यहां संचालित डोमेन पर जाना पसंद करूंगा, मौजूदा में प्रॉपर्टी को जोड़ना या उसके लिए नया बीन बनाना उचित होगा। जो कभी भी बेहतर सूट करता है। मुझे नहीं लगता कि इसके लिए कोई चांदी की गोली है।

• कौन सा गुण किस बैकिंग बीन का है। खैर, क्या यह डोमेन ऑब्जेक्ट पर निर्भर नहीं है? या यह सवाल हो सकता है कि स्पष्ट नहीं है।

इसके अलावा, आपके दिए गए कोड उदाहरण में, मुझे कोई बड़ा लाभ नहीं दिखाई दे रहा है।

Comments

यदि - उदाहरण के लिए - हम JDBC प्रश्नों के साथ बनाए गए होम-ब्रूएड POJOs का उपयोग करने से बदल रहे थे, तो हाइबरनेट संस्थाओं के लिए, जिनके क्षेत्र अलग-अलग थे, हमें न केवल बैकिंग बीन को बदलना होगा। हमें JSF पेज भी बदलना होगा। मेरे कोड उदाहरण के साथ ऐसा नहीं है। बस बीन बदलो।

— Zack Marrapese

उस मामले में आप अपने समर्थन सेम, संस्थाओं बना सकते हैं। फिर आपको बस JSF पेज बदलने की जरूरत है। या यह निर्भर करता है कि आप संपत्तियों का नाम फिर भी क्यों बदलेंगे? यह तभी समझ में आएगा जब आप अपने डेटाबेस कॉलम के नाम से मेल खाने के लिए फ़ील्ड का नाम बदलें। लेकिन एक अलग मामला है, पूरी तरह से।

— आदिल अंसारी

Answer 5

मैं आवश्यक नहीं होगा कि प्रति पृष्ठ केवल एक बैकिंग बीन रखूं। यह कार्यक्षमता पर निर्भर करता है, लेकिन ज्यादातर समय मैं प्रति पेज एक सेम था क्योंकि ज्यादातर एक पृष्ठ एक कार्यक्षमता को संभालता है। उदाहरण के लिए एक पृष्ठ पर मेरे पास एक रजिस्टर लिंक है (मैं रजिस्टरबिन के साथ लिंक करूंगा) और एक शॉपिंग बास्केट लिंक (शोपिंगबैसेटबीन)।

मैं इसका उपयोग करता हूं <: outputText मान = "# {myBean.anObject.anObjectProperty}" /> जैसा कि मैं आम तौर पर एक्शन बीन्स के रूप में सेम को समर्थन में रखता हूं जो डेटा ऑब्जेक्ट रखती है। मैं अपने डेटा ऑब्जेक्ट्स के गुणों तक पहुँचने के लिए अपने बैकिंग बीन में एक आवरण लिखना नहीं चाहता।

Answer 6

मुझे व्यू के बिना बिजनेस कोड का परीक्षण करना पसंद है, इसलिए मैं बैकिंगबीन्स को व्यू से मॉडल कोड के इंटरफेस के रूप में मानता हूं। मैंने कभी भी एक BackingBean में कोई नियम या प्रक्रिया नहीं रखी। यह कोड पुन: उपयोग की अनुमति देते हुए सेवा या सहायकों में चला जाता है।

यदि आप सत्यापनकर्ताओं का उपयोग करते हैं, तो उन्हें अपने बैकिंगबैन से बाहर रखें और उन्हें अपने सत्यापन विधि से संदर्भित करें।

यदि आप चयन, रेडियो, चेकबॉक्स भरने के लिए डीएओ तक पहुंचते हैं, तो हमेशा एक बैकिंग बीन से बाहर निकलें।

मुझ पर विश्वास करो!। आप एक जावा बीन को एक बैकिंग बीन में इंजेक्ट कर सकते हैं, लेकिन बैकिंग बीन को दूसरे में इंजेक्ट करने का प्रयास करें। आप जल्द ही रखरखाव और समझ कोड के एक nigntmare में होंगे।