क्या एमवीसी पैटर्न अनुप्रयोग विकास के लिए एक मृत अंत है?

इस लेख में, मैं इस बारे में बात करना चाहूंगा कि MVC डिज़ाइन पैटर्न का उपयोग करना लचीला और स्केलेबल एप्लिकेशन बनाने के लिए पर्याप्त क्यों नहीं है। और पहचान की गई समस्याओं के समाधान भी प्रस्तुत करते हैं।

मॉडल व्यू कंट्रोलर टेम्पलेट में कुछ भी गलत नहीं है। यह उस समस्या को हल करता है जिसके लिए इसका आविष्कार किया गया था - यह उपयोगकर्ता के अनुरोध को संसाधित करने के तर्क और सूचना प्रस्तुत करने के तर्क का अलगाव है।




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



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



इस मामले में, उसे पता होना चाहिए कि आवश्यक बदलाव करने के लिए सिस्टम मॉड्यूल के साथ किस क्रम में काम करना है।

साथ ही, यदि सिस्टम के साथ काम करने की प्रक्रिया बदल गई है (व्यवसाय या डोमेन मॉडल बदल गया है), तो उपयोगकर्ता सिस्टम के उपयोगकर्ता इंटरफ़ेस में बदलाव किए बिना नई प्रक्रिया सीख सकता है।

जब तक सिस्टम का उपयोग बहुत कम लोगों द्वारा किया जाता है, तब तक सब कुछ ठीक है, जिन्हें इसके साथ काम करने के लिए प्रशिक्षित किया जा सकता है।

लेकिन क्या होगा अगर सिस्टम कई उपयोगकर्ताओं के लिए आता है?

सिस्टम के उपयोग को सरल बनाने के लिए, आप इसे बना सकते हैं ताकि यह खुद ही जान सके कि इसके साथ किस क्रम में काम करना है और उपयोगकर्ता को आगे के कदम प्रदान करता है।

लेकिन यहाँ MVC टेम्पलेट का उपयोग करने की जिद निहित है। जैसा कि नीचे दी गई छवि में दिखाया गया है, यह मॉड्यूल 'बी' से मॉड्यूल 'बी' से मॉड्यूल 'सी' से मॉड्यूल 'डी' से मॉड्यूल 'बी' से मॉड्यूल 'बी' के नियंत्रक 'नियंत्रक' के दृश्य से सीधे संदर्भित करने के लिए आकर्षक है। ।


(या मॉड्यूल नियंत्रक 'ए' से मॉड्यूल 'बी' के नियंत्रक के लिए। या, मॉड्यूल 'बी' के देखने के लिए मॉड्यूल 'ए' के ​​नियंत्रक से भी बदतर।)

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

दुर्भाग्य से, इस दृष्टिकोण का उपयोग अक्सर अनुप्रयोगों के निर्माण के लिए किया जाता है।

सिस्टम मॉड्यूल के पूर्व कमजोर सुसंगतता को कैसे वापस करना है, जबकि इसके अंदर व्यापारिक प्रक्रियाओं का विवरण बनाए रखना है?



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

मॉड्यूल राज्य और उनके बीच संक्रमण को कॉन्फ़िगर करने के लिए Finite State Machine कार्यान्वयन का उपयोग करना बहुत सुविधाजनक है।

जावा दुनिया में ऐसे कार्यान्वयन के उदाहरण हैं:

• स्प्रिंग वेब फ्लो - स्प्रिंग एमवीसी के लिए ऐड-ऑन।

• ओरेकल के एडीएफ टास्क फ्लो - कार्यान्वयन स्प्रिंग वेब फ्लो के समान है।

• लेक्सडेन वेब फ्लो - वाडिन घटक मॉडल के लिए कार्यान्वयन।

इस दृष्टिकोण के अन्य कार्यान्वयन क्या आप जावा में जानते हैं?
शायद अन्य प्रोग्रामिंग भाषाओं के लिए समान रूपरेखाएं हैं?

पीपीएस कार्यान्वयन लेक्सडेन वेब फ्लो और वाडिन के लिए वर्णित समाधान का विवरण लेख में विस्तार से वर्णित किया गया है: नेविगेशन: कॉर्पोरेट आवेदन के लिए कार्यान्वयन विकल्प