5

प्रश्न मुश्किल हो सकता है (इसकी प्रकृति या इसका वर्णन करने का मेरा तरीका), इसलिए जवाब देने से पहले इसे वास्तव में पढ़ें।डेस्कटॉप एप के लिए एमवीसी बिना डाटा लेयर

मेरे पास यह ऐप लिखने के लिए है:
ए) डेस्कटॉप ऐप;
बी) डेटाबेस, फ़ाइलों या किसी अन्य भंडार के अर्थ में कोई डेटा परत नहीं (डेटा को सहेजने, स्टोर करने या लोड करने की कोई आवश्यकता नहीं है);
सी) ऐप में कुछ गणना एल्गोरिदम लागू होंगे (जेनेटिक एल्गोरिदम);
बी) जीयूआई प्रदान करता है जो ऐप और गणना परिणामों के लिए नियंत्रण प्रदर्शित करेगा।

मैं एमवीसी पैटर्न का उपयोग करने के बारे में सोच रहा हूं लेकिन मुझे संदेह है कि इसका उपयोग कैसे करें। चूंकि मेरे पास (उदाहरण के लिए) डेटाबेस (डेटा इनपुट के आधार पर निष्पादन के दौरान डेटा उत्पन्न होता है) के अर्थ में कोई डेटा परत नहीं है, इसलिए मैं इस कार्यान्वयन में एमवीसी का उपयोग करने के तरीके के बारे में चिंतित हूं। अब तक मैं दो दृष्टिकोणों के साथ आया हूं:

  1. GUI दृश्य है। जेनेटिक एल्गोरिदम नियंत्रक है। जेनेटिक एल्गोरिदम रिसेल्ट्स मॉडल है (कक्षा के रूप में जो केवल डेटा स्टोर करता है)। मूल प्रवाह:

    • व्यू नियंत्रक को उपयोगकर्ता इनपुट भेजता है;
    • नियंत्रक उपयोगकर्ता इनपुट को संसाधित कर रहा है और डेटा उत्पन्न करता है;
    • नियंत्रक मॉडल को जेनरेट डेटा भेजता है;
    • मॉडल नए डेटा के बारे में दृश्य को सूचित करता है;
    • व्यू नया डेटा खींचता है और प्रदर्शन को अपडेट करता है।
  2. जीयूआई दृश्य है। AppEngine नियंत्रक है। जेनेटिक एल्गोरिदम नड जेनेटिक एल्गोरिदम रिसेल्ट मॉडल हैं। अब हमारे पास है:

    • व्यू नियंत्रक को उपयोगकर्ता इनपुट भेजता है;
    • नियंत्रक उपयोगकर्ता इनपुट को संसाधित कर रहा है और मॉडल को नियंत्रण सिग्नल भेजता है।
    • मॉडल अपने आंतरिक स्थिति को अद्यतन करता है (नया डेटा उत्पन्न करता है);
    • मॉडल नियंत्रक को नए डेटा के बारे में सूचित करता है;
    • नियंत्रक डेटा को मॉडल खींचता है;
    • नियंत्रक डेटा संसाधित करता है;
    • नियंत्रक संसाधित डेटा को दृश्य में धक्का देता है;
    • दृश्य प्रदर्शन को अद्यतन करता है।

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

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

आप किस दृष्टिकोण की सिफारिश करेंगे? या शायद मुझे उन्हें मिश्रण करना चाहिए और दूसरे दृष्टिकोण से संचार प्रवाह के साथ पहली दृष्टिकोण वास्तुकला का उपयोग करना चाहिए? या कुछ अलग डिजाइन?

उत्तर

2

एमवीसी की मेरी समझ से, दूसरा संस्करण सख्त एमवीसी प्रतिमान की तरह है। हालांकि, मेरे बहुत बुद्धिमान शिक्षकों में से एक ने मुझे एक बार कहा था कि डिज़ाइन पैटर्न दिशानिर्देशों का ढीला सेट देने के लिए हैं और टी

मेरी राय में, दोनों का मिश्रण एक है अच्छा विचार। यदि मॉडल में कुछ तर्क समाप्त होते हैं, तो यह दुनिया का अंत नहीं है, इसका मतलब यह है कि आपको अपने घटकों को अलग करने का ट्रैक रखने के बारे में अधिक सावधान रहना होगा। यदि एमवीसी में एक छोटा सा संशोधन आपके जीवन को 50% आसान बनाता है (कम संदेश ओवरहेड), तो शायद यह एक अच्छा विचार है।

1

मैं निश्चित रूप से दूसरे कार्यान्वयन के करीब कुछ के साथ जाऊंगा। हां, ऐसा लगता है कि अधिक संदेश आगे और आगे जाते हैं, लेकिन यदि आपका आवेदन बढ़ता है और बदलता है, तो आप खुश होंगे कि आपने छोटे वर्गों के साथ एप्लिकेशन बनाया है।

विचार करें: एल्गोरिदम के बीच स्विचिंग, उन्हें निष्पादित करने और देखने के लिए डेटा को प्रोसेस करने जैसे सांसारिक कार्यों को संभालने का तर्क कहां है?

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

आपको अपने एल्गोरिदम को लागू करने के लिए रणनीति पैटर्न का उपयोग करना चाहिए। यह आपको प्रत्येक एल्गोरिदम के लिए व्यावसायिक तर्क बदलने के बिना आनुवांशिक एल्गोरिदम से आपके अन्य एल्गोरिदम में आपके सॉल्वर के कार्यान्वयन को बदलने की अनुमति देगा।

व्यापार परत एक आईएसओवरवर देखेंगे जो इनपुट लेती है, और आप mySolver.Solve() को कॉल करेंगे। आप अपने व्यापार परत तर्क (Open Closed Principle) को बदलने के बिना विभिन्न संस्करणों के बीच स्विच करने में सक्षम होना चाहिए। व्यापार तर्क को एल्गोरिदम के साथ बातचीत करने के तरीके में एकमात्र अंतर कन्स्ट्रक्टर में होना चाहिए, और यहां तक ​​कि, आपको फैक्ट्री पैटर्न का उपयोग करने पर विचार करना चाहिए।

संबंधित मुद्दे