के शीर्ष पर एक प्लगइन आधारित आर्किटेक्चर का विकास करना, मैं अपने वर्तमान ऐप्स में से एक के लिए स्प्रिंग के शीर्ष पर एक साधारण प्लगइन आधारित आर्किटेक्चर विकसित करने के आसपास अपने सिर को खरोंच कर रहा हूं। कोई फर्क नहीं पड़ता कि एमवीसी जैसे पैटर्न का उपयोग करके कोई कितना अलगाव प्राप्त कर सकता है, एक हमेशा उस बिंदु तक पहुंच जाता है जहां युग्मन अनिवार्य है।स्प्रिंग
इस प्रकार, मैंने विकल्पों का वजन शुरू किया। पहले मैंने सोचा कि फिल्टर एक अच्छा है। मैं जो भी प्लगइन बनाना चाहता हूं वह एक फ़िल्टर होगा, जो तब मैं फ़िल्टर मानचित्र में बस डालेगा। बेशक, यह सभी फ़िल्टरों की गणना और जांच करते समय थोड़ा अधिक ओवरहेड बनाएगा, लेकिन कम से कम, नियंत्रकों को यह ध्यान नहीं रखना होगा कि डेटा तक पहुंचने से पहले क्या हुआ है, या बाद में क्या होता है, वे केवल देखभाल करेंगे मॉडल लाएं (डीएओ या व्हाट्नॉट के माध्यम से) और उन्हें वापस कर दें।
समस्या यह है कि मेरे सभी ऐप अनुरोध HTTP-आधारित नहीं हैं। कुछ ईमेल पर आधारित होते हैं, अन्य आंतरिक रूप से निर्धारित होते हैं (समयबद्ध), इसलिए फ़िल्टर अधिक मदद नहीं करेंगे, जब तक कि मैं HTTPRequest को हर प्रकार के आने वाले अनुरोध को अनुकूलित करने का प्रयास नहीं करता, जो बहुत अधिक होगा।
एक और जिसे मैंने सोचा था एओपी आधारित एनओपी था, जहां मैं हर विधि को एनोटेट करता हूं, जहां प्लगइन कुछ सम्मेलनों के आधार पर विधियों को रोक देगा। मेरी समस्या यह है कि सबसे पहले मैं आम तौर पर एओपी के साथ इतना अनुभवी नहीं हूं, और दूसरा, बस उन सभी सम्मेलनों को लिखना पहले से ही कुछ युग्मन का सुझाव देता है
अब तक विकल्प जो मेरे सोचने के तरीके से अपील करता है, वसंत- आधारित घटनाओं। मेरे ऐप (वेब कंट्रोलर, ईमेल हैंडलर इत्यादि) के भीतर हर प्रकार का अनुरोध हैंडलर एक इवेंट डिस्पैचर का एक प्रकार होगा, जो प्रत्येक प्रमुख कार्रवाई पर स्प्रिंग घटनाओं को प्रेषित करेगा। दूसरी ओर, जब कोई विशेष घटना होती है, तो प्लगइन बस सुनेंगे, और कुछ तर्क करें। यह मुझे बिंदु # 1 का भी उपयोग करने की अनुमति देगा, क्योंकि उनमें से कुछ प्लगइन फ़िल्टर भी हो सकते हैं, यानी जब उन्हें एक अधिसूचना मिलती है कि एक निश्चित नियंत्रक कार्रवाई की जाती है, तो वे केवल कुछ भी करने का फैसला नहीं कर सकते हैं, बल्कि इसके लिए प्रतीक्षा कर सकते हैं उन्हें फिल्टर श्रृंखला द्वारा बुलाया जाता है। मैं इसे कुछ हद तक अच्छा दृष्टिकोण के रूप में देखता हूं। निस्संदेह यहां उपरोक्त आते हैं, घटनाओं को प्रेषित करने के साथ-साथ तथ्य यह भी है कि प्रत्येक शामिल वर्ग हमेशा के लिए वसंत के साथ मिल जाएगा, लेकिन मैं इसे एक आवश्यक बुराई के रूप में देखता हूं।
स्प्रिंग इवेंट्स के बारे में मेरी मुख्य चिंता विलंबता और स्मृति पदचिह्न के मामले में प्रदर्शन है।
मैं अभी भी एक विशेषज्ञ नहीं हूं, इसलिए यहां प्रतिक्रिया का एक समूह जबरदस्त सहायता होगी। वसंत घटनाएं इस प्रकार के वास्तुकला के लिए सबसे अच्छी हैं, या एक और समाधान है जिसे मैंने याद किया है? मुझे पता है कि वहां पहले से ही कुछ तीसरे पक्ष के समाधान भी हो सकते हैं, इसलिए अगर कोई एक या दो कोशिश करने वाले और साबित लोगों को इंगित कर सकता है तो मुझे खुशी होगी।
धन्यवाद।
के रूप में दिलचस्प यह सवाल है के रूप में, मैं इसे यहाँ विषय बंद पूरी तरह से है कहेंगे और मैं "के रूप में रचनात्मक नहीं" बंद करने के लिए मतदान कर रहा हूँ (परिभाषा पढ़ सकते हैं और आप शायद इस बात से सहमत होगा)। मुझे लगता है कि वसंत मंच/मेलिंग सूचियां इस बारे में बात करने की जगह हैं। –
मैं नहीं दिख रहा है यही कारण है कि इस सवाल का रचनात्मक या विषय से दूर बिल्कुल नहीं है। –