चलो जावा आधारित वेब एप्लिकेशन आर्किटेक्चर साझा करते हैं!
वेब एप्लिकेशन के लिए बहुत सारे अलग-अलग आर्किटेक्चर हैं जिन्हें जावा का उपयोग करके लागू किया जाना है। इस सवाल के जवाब उनके पेशेवरों और विपक्षों के साथ विभिन्न वेब एप्लिकेशन डिज़ाइनों के पुस्तकालय के रूप में काम कर सकते हैं। जबकि मुझे एहसास है कि उत्तर व्यक्तिपरक होंगे, आइए हम उतने ही उद्देश्य के साथ प्रयास करें जितना हम कर सकते हैं और हमारे द्वारा सूचीबद्ध पेशेवरों और विपक्षों को प्रेरित कर सकते हैं।
अपने आर्किटेक्चर का वर्णन करने के लिए आपके द्वारा पसंद किए गए विवरण स्तर का उपयोग करें। किसी भी मूल्य के आपके उत्तर के लिए आपको कम से कम वास्तुकला में उपयोग की जाने वाली प्रमुख तकनीकों और विचारों का वर्णन करना होगा। और अंतिम लेकिन कम से कम, हमें आपकी वास्तुकला का उपयोग कब करना चाहिए?
मैं शुरू करूँगा...
वास्तुकला का अवलोकन
हम जावा से ईई, जावा पर्सिस्टेंस एपीआई, सर्वलेट और जावा सर्वर पेज जैसे खुले मानकों के आधार पर 3-स्तरीय वास्तुकला का उपयोग करते हैं।
- हठ
- व्यापार
- प्रस्तुतीकरण
परतों के बीच संभावित संचार प्रवाह द्वारा दर्शाया जाता है:
Persistence <-> Business <-> Presentationउदाहरण के लिए, इसका मतलब है कि प्रेजेंटेशन लेयर कभी भी कॉल नहीं करता है या दृढ़ता से काम करता है, यह हमेशा व्यापार परत के माध्यम से करता है। यह आर्किटेक्चर एक उच्च उपलब्धता वेब एप्लिकेशन की मांगों को पूरा करने के लिए है।
हठ
क्रिएट, रीड, अपडेट और डिलीट ( CRUD ) दृढ़ता ऑपरेशन करता है। हमारे मामले में हम ( जावा पर्सिस्टेंस एपीआई ) जेपीए का उपयोग कर रहे हैं और हम वर्तमान में अपने दृढ़ता प्रदाता के रूप में हाइबरनेट का उपयोग करते हैं और इसके एंटिटी मैनजर का उपयोग करते हैं ।
इस परत को कई वर्गों में विभाजित किया गया है, जहां प्रत्येक वर्ग एक निश्चित प्रकार की संस्थाओं (यानी एक शॉपिंग कार्ट से संबंधित इकाइयाँ, एक एकल वर्ग द्वारा नियंत्रित की जा सकती हैं) और एक और केवल एक प्रबंधक द्वारा उपयोग किया जाता है ।
इसके अलावा इस परत में जेपीए इकाइयाँ भी जमा होती हैं Account, जैसे कि चीजें , ShoppingCartआदि।
व्यापार
सभी तर्क जो वेब एप्लिकेशन कार्यक्षमता से बंधा है, इस परत में स्थित है। यह कार्यक्षमता उस ग्राहक के लिए धन हस्तांतरण शुरू कर सकती है, जो अपने क्रेडिट कार्ड का उपयोग करके किसी उत्पाद के लिए भुगतान करना चाहता है। यह सिर्फ एक नया उपयोगकर्ता बना सकता है, एक उपयोगकर्ता को हटा सकता है या वेब आधारित गेम में लड़ाई के परिणाम की गणना कर सकता है।
इस परत को कई वर्गों में विभाजित किया गया है और इनमें से प्रत्येक वर्ग को स्टेटलेस सत्र बीन (SLSB) @Statelessबनने के लिए एनोटेट किया गया है । प्रत्येक SLSB को प्रबंधक कहा जाता है और उदाहरण के लिए एक प्रबंधक एक वर्ग हो सकता है जैसा कि वर्णित है ।AccountManager
जब AccountManagerCRUD ऑपरेशन करने की आवश्यकता होती है तो यह एक उदाहरण के लिए उपयुक्त कॉल AccountManagerPersistenceकरता है, जो दृढ़ता परत में एक वर्ग है। AccountManagerहो सकता है दो तरीकों का एक मोटा स्केच :
...
public void makeExpiredAccountsInactive() {
AccountManagerPersistence amp = new AccountManagerPersistence(...)
// Calls persistence layer
List<Account> expiredAccounts = amp.getAllExpiredAccounts();
for(Account account : expiredAccounts) {
this.makeAccountInactive(account)
}
}
public void makeAccountInactive(Account account) {
AccountManagerPersistence amp = new AccountManagerPersistence(...)
account.deactivate();
amp.storeUpdatedAccount(account); // Calls persistence layer
}हम कंटेनर प्रबंधक लेनदेन का उपयोग करते हैं, इसलिए हमें अपने स्वयं के लेन-देन का सीमांकन नहीं करना है। मूल रूप से हुड के नीचे क्या होता है हम एसएलएसबी विधि में प्रवेश करते समय एक लेनदेन शुरू करते हैं और विधि से बाहर निकलने से तुरंत पहले इसे (या इसे रोलबैक) करते हैं। यह कॉन्फ़िगरेशन पर कन्वेंशन का एक उदाहरण है, लेकिन हमें किसी भी चीज़ की आवश्यकता नहीं है लेकिन डिफ़ॉल्ट, आवश्यक है, फिर भी।
यहाँ बताया गया है कि सूर्य से जावा EE 5 ट्यूटोरियल एंटरप्राइज JavaBeans (EJB's) के लिए आवश्यक लेनदेन विशेषता बताता है :
यदि ग्राहक लेन-देन के भीतर चल रहा है और एंटरप्राइज़ बीन की विधि को लागू करता है, तो विधि क्लाइंट के लेनदेन के भीतर निष्पादित होती है। यदि ग्राहक लेन-देन से संबद्ध नहीं है, तो विधि को चलाने से पहले कंटेनर एक नया लेनदेन शुरू करता है।
आवश्यक विशेषता कंटेनर-प्रबंधित लेनदेन सीमांकन के साथ चलने वाले सभी एंटरप्राइज़ बीन विधियों के लिए निहित लेनदेन विशेषता है। जब तक आपको किसी अन्य लेन-देन विशेषता को ओवरराइड करने की आवश्यकता न हो, आप आमतौर पर आवश्यक विशेषता सेट नहीं करते हैं। क्योंकि लेन-देन की विशेषताएँ घोषणात्मक हैं, आप उन्हें बाद में आसानी से बदल सकते हैं।
प्रस्तुतीकरण
हमारी प्रस्तुति परत के प्रभारी है ... प्रस्तुति! यह उपयोगकर्ता इंटरफ़ेस के लिए ज़िम्मेदार है और उपयोगकर्ता को HTML पृष्ठ बनाने और GET और POST अनुरोधों के माध्यम से उपयोगकर्ता इनपुट प्राप्त करने के लिए जानकारी दिखाता है। वर्तमान में हम पुराने सर्वलेट + जावा सर्वर पेज ( JSP ) संयोजन का उपयोग कर रहे हैं ।
परत उपयोगकर्ता द्वारा अनुरोध किए गए कार्यों को निष्पादित करने और वेब पेज में दिखाने के लिए जानकारी प्राप्त करने के लिए व्यावसायिक परत के प्रबंधकों में विधियों को कॉल करती है । कभी कभी व्यापार परत से प्राप्त जानकारी के रूप में कम जटिल प्रकार के होते हैं Stringकी और integers, और अन्य समय पर जेपीए संस्थाओं ।
वास्तुकला के साथ पेशेवरों और विपक्ष
पेशेवरों
- इस परत में दृढ़ता से करने के एक विशिष्ट तरीके से संबंधित सब कुछ होने का मतलब है कि हम व्यावसायिक परत में कुछ भी फिर से लिखने के बिना, जेपीए का उपयोग किसी और चीज़ में करने से स्वैप कर सकते हैं।
- हमारे लिए अपनी प्रस्तुति परत को किसी और चीज़ में बदलना आसान है, और यह संभव है कि हम कुछ बेहतर पाएंगे।
- EJB कंटेनर को लेन-देन की सीमाओं को प्रबंधित करने देना अच्छा है।
- सर्वलेट के JPA का उपयोग करना आसान है (साथ शुरू करना) और तकनीकों का व्यापक रूप से उपयोग किया जाता है और बहुत सारे सर्वरों में लागू किया जाता है।
- जावा ईई का उपयोग करना हमारे लिए लोड संतुलन के साथ एक उच्च उपलब्धता प्रणाली बनाने और इसे विफल करने के लिए आसान बनाने वाला है । दोनों जो हमें लगता है कि हमारे पास होना चाहिए।
विपक्ष
- जेपीए के उपयोग से आप
@NamedQueryजेपीए इकाई वर्ग पर एनोटेशन का उपयोग करके अक्सर पूछे जाने वाले प्रश्नों को स्टोर कर सकते हैं । यदि आपके पास दृढ़ता कक्षाओं में दृढ़ता से संबंधित जितना संभव हो, हमारी वास्तुकला में, यह उन स्थानों को फैलाएगा जहां आपको जेपीए संस्थाओं को शामिल करने के लिए प्रश्न मिल सकते हैं। दृढ़ता संचालन को बनाए रखना कठिन होगा और इस प्रकार बनाए रखना कठिन होगा। - हमारे पास हमारी दृढ़ता परत के हिस्से के रूप में जेपीए इकाइयाँ हैं। लेकिन
AccountऔरShoppingCart, नहीं वे वास्तव में व्यापार वस्तुओं रहे हैं? यह इस तरह से किया जाता है जैसे आपको इन वर्गों को छूना है और उन्हें उन संस्थाओं में बदलना है जिन्हें जेपीए जानता है कि कैसे संभालना है। - जेपीए इकाइयाँ, जो हमारी व्यावसायिक वस्तुएँ भी हैं, डेटा ट्रांसफर ऑब्जेक्ट्स ( डीटीओ ) की तरह बनाई जाती हैं , जिन्हें वैल्यू ऑब्जेक्ट्स (वीओ) भी कहा जाता है। यह एनीमिक डोमेन मॉडल के रूप में परिणाम देता है क्योंकि व्यापारिक वस्तुओं के पास एक्सेसर विधियों को छोड़कर खुद का कोई तर्क नहीं है। सभी तर्क हमारे प्रबंधकों द्वारा व्यापार परत में किए जाते हैं, जिसके परिणामस्वरूप एक अधिक प्रक्रियात्मक प्रोग्रामिंग शैली होती है। यह अच्छी वस्तु उन्मुख डिजाइन नहीं है, लेकिन शायद यह कोई समस्या नहीं है? (सभी ऑब्जेक्ट ओरिएंटेशन के बाद केवल प्रोग्रामिंग प्रतिमान नहीं है जिसने परिणाम दिया है।)
- EJB और Java EE का उपयोग करना थोड़ी जटिलता का परिचय देता है। और हम विशुद्ध रूप से टॉमकैट का उपयोग नहीं कर सकते हैं (एक EJB माइक्रो-कंटेनर जोड़कर विशुद्ध रूप से टॉमकैट नहीं है )।
- सर्वलेट के + जेपीए का उपयोग करने के साथ बहुत सारे मुद्दे हैं। इन मुद्दों के बारे में अधिक जानकारी के लिए Google का उपयोग करें।
- जब व्यापार परत से बाहर निकलते समय लेन-देन बंद हो जाता है, तो हम जेपीए संस्थाओं से कोई भी जानकारी लोड नहीं कर सकते हैं, जिसे डेटाबेस से लोड होने के लिए कॉन्फ़िगर किया जाता है जब इसे
fetch=FetchType.LAZYप्रस्तुति परत के अंदर से जरूरत (उपयोग ) होती है। यह एक अपवाद को ट्रिगर करेगा। इस प्रकार के क्षेत्रों से युक्त एक इकाई को वापस करने से पहले हमें संबंधित गेटर्स को कॉल करना सुनिश्चित करना होगा। एक और विकल्प जावा पर्सिस्टेंस क्वेरी लैंग्वेज ( JPQL ) का उपयोग करना और एक करना हैFETCH JOIN। हालाँकि ये दोनों विकल्प थोड़े बोझिल हैं।