8
सत्र फ़ैकेड कोर जे 2 ईई पैटर्न के फायदे और नुकसान क्या हैं?सत्र फ़ैकेड कोर जे 2 ईई पैटर्न के फायदे और नुकसान क्या हैं?
इसके पीछे क्या धारणाएं हैं?
क्या ये धारणा किसी विशेष वातावरण में मान्य हैं?
A
उत्तर
6
सत्र फेकाडे एक शानदार पैटर्न है - यह वास्तव में बिजनेस फेकाडे पैटर्न का एक विशिष्ट संस्करण है। विचार अलग-अलग बंडलों में व्यापार कार्यक्षमता को जोड़ना है - जैसे ट्रांसफरमोनी(), निकालना(), जमा() ... ताकि आपका यूआई कोड निम्न स्तर की डेटा पहुंच या अन्य विवरणों के बजाय व्यवसाय संचालन के मामले में चीजों तक पहुंच रहा हो कि इससे चिंतित नहीं होना चाहिए।
सत्र फसाड साथ विशेष रूप से- यदि आप व्यापार मुखौटा के रूप में कार्य करने के लिए एक सत्र EJB का उपयोग करें - जो तब अच्छा कारण है कि आप सभी J2EE सेवाएं (प्रमाणीकरण/प्राधिकरण, लेन-देन, आदि) का लाभ ले सकते ...
उम्मीद है कि मदद करता है ...
0
सत्र फेकाडे पैटर्न का मुख्य लाभ यह है कि आप व्यावसायिक कार्यक्षमता द्वारा लॉजिकल समूहों में एक जे 2 ईई अनुप्रयोग को विभाजित कर सकते हैं। एक सत्र फेकाडे को यूआई (यानी एक व्यवसाय प्रतिनिधि) से पीओजेओ द्वारा बुलाया जाएगा, और उचित डेटा एक्सेस ऑब्जेक्ट्स के संदर्भ होंगे। जैसे एक PersonSessionFacade को PersonBusinessDelegate द्वारा बुलाया जाएगा और फिर यह PersonDAO को कॉल कर सकता है। PersonSessionFacade पर विधियां, कम से कम, CRUD पैटर्न का पालन करें (बनाएं, पुनर्प्राप्त करें, अपडेट करें और हटाएं)।
आमतौर पर, अधिकांश सत्र फ़ेडेड को स्टेटलेस सत्र ईजेबी के रूप में लागू किया जाता है। या यदि आप लेनदेन के लिए एओपी का उपयोग कर स्प्रिंग भूमि में हैं, तो आप एक सेवा POJO बना सकते हैं जो आपके लेनदेन प्रबंधक के लिए सभी शामिल बिंदु हो सकता है।
सत्र फ़ैकेड पैटर्न का एक अन्य लाभ यह है कि किसी भी जे 2 ईई डेवलपर को अनुभव के एक मॉडल के साथ तुरंत आपको समझ जाएगा।
सत्र फ़ैकेड पैटर्न के नुकसान: यह एक विशिष्ट उद्यम आर्किटेक्चर मानता है जो जे 2 ईई 1.4 विनिर्देश की सीमाओं से बाधित है (इन आलोचनाओं के लिए रॉड जॉनसन की पुस्तकें देखें)। सबसे हानिकारक नुकसान यह है कि यह आवश्यक से अधिक जटिल है। अधिकांश एंटरप्राइज़ वेब एप्लिकेशन में, आपको एक सर्वलेट कंटेनर की आवश्यकता होगी, और वेब एप्लिकेशन में अधिकांश तनाव उस स्तर पर होगा जो HttpRequests या डेटाबेस एक्सेस को नियंत्रित करता है। नतीजतन, ईजेबी कंटेनर से एक अलग प्रक्रिया स्थान में सर्वलेट कंटेनर को तैनात करने के लिए उपयुक्त नहीं लगता है। अर्थात। ईजेबी को रिमोट कॉल लाभ से ज्यादा दर्द पैदा करते हैं।
0
रॉड जॉनसन का दावा है कि मुख्य कारण आप का उपयोग करने के लिए एक सत्र फसाड अगर आप कंटेनर में कामयाब लेनदेन कर रहे है चाहते हैं - (। स्प्रिंग की तरह) जो अधिक आधुनिक चौखटे के साथ आवश्यक नहीं हैं
वह कहता है अगर आपके पास व्यवसाय तर्क है - इसे पीओजेओ में डाल दें। (जो मैं मानता हूं - मुझे लगता है कि यह एक अधिक ऑब्जेक्ट उन्मुख दृष्टिकोण है - एक सत्र ईजेबी लागू करने के बजाए।) http://forum.springframework.org/showthread.php?t=18155
विपरीत तर्क सुनने के लिए खुश।
0
ऐसा लगता है कि जब भी आप जे 2 ईई से संबंधित किसी भी चीज के बारे में बात करते हैं - दृश्यों के पीछे हमेशा धारणाओं का एक पूरा समूह होता है - जो लोग एक तरफ या दूसरे को मानते हैं - जो तब भ्रम पैदा करता है। (शायद मैं सवाल भी स्पष्ट कर सकता था।)
मान लिया जाये कि (क) हम EJB विनिर्देश के माध्यम से एक सही मायनों में यह कंटेनर में कामयाब लेनदेन उपयोग करने के लिए तो
सत्र अग्रभाग में एक अच्छा विचार कर रहे हैं चाहते हैं - क्योंकि वे सार दूर निम्न स्तर के डेटाबेस लेनदेन करने में सक्षम हो उच्च स्तर आवेदन लेनदेन प्रबंधन प्रदान करते हैं।
मान लिया जाये कि (ख) कि आप सत्र बहाना के सामान्य वास्तुकला की अवधारणा का मतलब - तो
Decoupling सेवाओं और उपभोक्ताओं और इस के शीर्ष पर एक अनुकूल इंटरफेस उपलब्ध कराने के एक अच्छा विचार है। कंप्यूटर विज्ञान 'अविवेक की एक अतिरिक्त परत जोड़ने' द्वारा समस्याओं के बहुत सारे हल किया है।
रॉड जॉनसन लिखते हैं "रिमोट इंटरफेस के साथ एसएलएसबी आरएमआई पर वितरित वितरित अनुप्रयोगों के लिए एक बहुत अच्छा समाधान प्रदान करते हैं। हालांकि, यह अल्पसंख्यक आवश्यकता है। अनुभव से पता चला है कि हम वितरित आर्किटेक्चर का उपयोग नहीं करना चाहते हैं जब तक कि आवश्यकताओं के अनुसार मजबूर नहीं किया जाता । हम अभी भी एक अच्छा सह स्थित ऑब्जेक्ट मॉडल के शीर्ष पर एक दूरस्थ बहाना को लागू करने से दूरस्थ क्लाइंट यदि आवश्यक हो तो सेवा कर सकते हैं। "
: (। जॉनसन, आर p119 "EJB बिना J2EE विकास")मान लिया जाये कि (ग) है कि आप EJB विनिर्देश पर विचार (और विशेष रूप से सत्र बहाना घटक) तो अच्छे डिजाइन के परिदृश्य को नुक़सान होने की
रॉड जॉनसन लिखते "सामान्य तौर पर, वहाँ नहीं कई कारण आप एक स्प्रिंग आवेदन में सब पर एक स्थानीय SLSB का प्रयोग करेंगे, के रूप में वसंत EJB की तुलना में अधिक सक्षम कथात्मक लेनदेन प्रबंधन प्रदान करता है, और CMT आम तौर पर स्थानीय SLSBs प्रयोग करने के लिए मुख्य प्रेरणा है कर रहे हैं इसलिए आपको ईजेबी परत की आवश्यकता नहीं हो सकती है। "http://forum.springframework.org/showthread.php?t=18155
ऐसे वातावरण में जहां वेब का प्रदर्शन और स्केलेबिलिटी सर्वर प्राथमिक चिंता कर रहे हैं - और लागत एक मुद्दा है - तो सत्र मुखौटा वास्तुकला कम आकर्षक लग रहा है - यह datbase से सीधे बात करने के लिए आसान हो सकता है
(हालांकि यह tiering के बारे में अधिक है।)