model-view-controller - Qt मॉडल / व्यू शब्दावली का दुरुपयोग क्यों कर रहा है?




(5)

मुझे लगता है कि मॉडल / दृश्य नियंत्रण के साथ क्यूटी में उपयोग की जाने वाली शब्दावली त्रुटिपूर्ण है। उनके स्पष्टीकरण पृष्ठ पर वे कहते हैं कि उन्होंने दृश्य और नियंत्रक विलय करके एमवीसी को एमवी को सरल बना दिया है और वे निम्नलिखित चित्र दे रहे हैं:

हालांकि मुझे लगता है, उन्होंने वस्तुओं की भूमिका का गलत नाम दिया और मुझे लगता है कि,

  1. विलय नियंत्रक के साथ वे क्या कहते हैं वास्तव में केवल एक दृश्य है।
  2. वे मॉडल को क्या कहते हैं वास्तव में केवल नियंत्रक है।
  3. यदि आप वास्तव में एक मॉडल चाहते हैं तो यह कहीं कहीं होगा जहां उनका "डेटा" है।

मैं सामान्य और सौहार्दपूर्ण तरीके से बात कर रहा हूं कि आप अपने ऐप में क्यूटी मॉडल / व्यू घटक का उपयोग करेंगे। यहां कारण हैं:

  1. यह आमतौर पर क्यूटी घटक होता है जिसका प्रयोग आपके ऑब्जेक्ट्स के लिए विशिष्ट नियंत्रक तर्क को जोड़ने के बिना किया जाता है)
  2. यह शायद ही एक मॉडल है, सिर्फ इसलिए कि आपको कई क्यूटी विधियों जैसे पंक्ति गणना, कॉलमकाउंट, डेटा इत्यादि को लागू करना चाहिए, जिनके आपके मॉडल के साथ कुछ लेना देना नहीं है। वास्तव में नियंत्रकों में पाए जाने वाले सामान्य मॉडल विधियां हैं। बेशक, आप कंट्रोलर और मॉडल तर्क दोनों को यहां कार्यान्वित कर सकते हैं, लेकिन पहले यह काफी खराब कोड डिज़ाइन होगा और दूसरी बात यह है कि आप कंट्रोलर और मॉडल को कंट्रोलर नहीं मर्ज करेंगे और जैसा कि वे कहते हैं देखें।
  3. जैसा कि कारण 2 में कहा गया है। यदि आप मॉडल तर्क को अलग करना चाहते हैं कि यह निश्चित रूप से चित्र पर नीला बॉक्स नहीं है, बल्कि "डेटा" बॉक्स को धक्का दिया गया है (पाठ्यक्रम के वास्तविक डेटा से संचार करना)।

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


Answers

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


संक्षिप्त जवाब

क्यूटी का एमवीसी केवल एक डेटा संरचना पर लागू होता है। एक एमवीसी अनुप्रयोग के बारे में बात करते समय आपको QAbstractItemModel या QListView बारे में नहीं सोचना चाहिए।

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

लंबा जवाब

क्यूटी का मॉडल / दृष्टिकोण दृष्टिकोण और शब्दावली:

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

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

एमवीसी शब्दावली में, मॉडल में डेटा और तर्क दोनों शामिल हैं। क्यूटी में, यह आपके ऊपर निर्भर करता है कि आप अपने मॉडल के अंदर अपना कुछ व्यावसायिक तर्क शामिल करते हैं या इसे अपने आप में "व्यू" होने के बाहर बाहर रखते हैं। यह तर्क भी नहीं है कि तर्क से क्या मतलब है: वस्तुओं का चयन, नामकरण और स्थानांतरित करना? => पहले ही लागू किया गया है। उनके साथ गणना करना? => मॉडल उपclass के बाहर या अंदर रखो। फ़ाइल से डेटा को संग्रहीत या लोड करना? => इसे मॉडल सबक्लास के अंदर रखें।

मेरी व्यक्तिगत राय:

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

मुझे लगता है कि क्यूटी का मॉडल / व्यू फ्रेमवर्क केवल तब उपयोगी होता है जब आप सरल डेटा संरचनाएं प्रदर्शित करना चाहते हैं। डेटा को कस्टम प्रकारों या संरचित नहीं किया जाता है, यदि पेड़ या सूची में नहीं है (उदाहरण के लिए एक ग्राफ)। ज्यादातर मामलों में, सूचियां पर्याप्त होती हैं और कुछ मामलों में भी, एक मॉडल को केवल एक ही प्रविष्टि रखना चाहिए। विशेष रूप से यदि आप अलग-अलग विशेषताओं (एक वर्ग का एक उदाहरण) वाले एक एकल प्रविष्टि को मॉडल करना चाहते हैं, तो क्यूटी का मॉडल / व्यू फ्रेमवर्क उपयोगकर्ता इंटरफ़ेस से तर्क को अलग करने का सही तरीका नहीं है।

चीजों को पूरा करने के लिए, मुझे लगता है कि क्यूटी का मॉडल / व्यू फ्रेमवर्क उपयोगी है अगर केवल तभी आपका डेटा क्यूटी के दर्शक विजेट्स में से एक द्वारा देखा जा रहा हो। यदि आप केवल एक प्रविष्टि वाले मॉडल के लिए अपना स्वयं का दर्शक लिखने वाले हैं, उदाहरण के लिए आपके एप्लिकेशन की सेटिंग्स, या यदि आपका डेटा प्रिंट करने योग्य प्रकारों का नहीं है, तो यह पूरी तरह बेकार है।

मैंने एक (बड़े) एप्लिकेशन के भीतर क्यूटी मॉडल / व्यू का उपयोग कैसे किया?

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

हमने तर्क कहाँ रखा? हमने उन वर्गों को बनाया जो स्रोत मॉडल से डेटा पढ़ने (डेटा बदलते समय) और डेटा को लक्ष्य मॉडल में लिखकर डेटा पर वास्तविक गणना करते थे। क्यूटी के दृष्टिकोण से, यह तर्क वर्ग विचार होंगे, क्योंकि वे मॉडल से "कनेक्ट" होते हैं (उपयोगकर्ता के लिए "दृश्य" नहीं, बल्कि एप्लिकेशन के व्यावसायिक तर्क भाग के लिए "दृश्य")।

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


शब्दावली सही या गलत नहीं है, यह उपयोगी या बेकार है।

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


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

  • MFC
  • क्यूटी
  • झूला
  • SWT
  • एमवीवीएम के साथ डब्ल्यूपीएफ

यदि आप तुलना करते हैं कि इन ढांचे में "मॉडल" और "व्यू" शब्द का उपयोग कैसे किया जाता है, और "दृश्य", "मॉडल" और "नियंत्रक" (यदि कोई है) में कक्षाएं क्या जिम्मेदारियां हैं, तो आप करेंगे पाते हैं कि बहुत बड़े अंतर हैं। यह निश्चित रूप से विभिन्न अवधारणाओं और शब्दावली की तुलना करने के लिए उपयोगी होगा, ताकि लोग एक ढांचे से दूसरे में स्विच करने के लिए सचेत रहने का मौका मिले, लेकिन इसके लिए बहुत सारे काम और शोध की आवश्यकता होगी। मार्टिन फाउलर का overview एक अच्छा पठन है।

चूंकि इतने सारे अलग-अलग विचार हैं कि एक एमवीसी पैटर्न कैसा दिख सकता है, कौन सा सही है? मेरी राय में, एमवीसी का आविष्कार करने वाले लोगों को तब बदला जाना चाहिए जब हम जानना चाहते हैं कि इसे "सही तरीके से" कैसे लागू किया जाना चाहिए। मूल स्मॉलटॉक पेपर में यह कहता है:

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

इसके प्रकाश में मैं आपकी तीन मुख्य चिंताओं का जवाब दूंगा:

  1. वास्तव में एक क्यूटी घटक "ग्राफिकल [...] आउटपुट" का प्रबंधन करता है, और "माउस और कीबोर्ड इनपुट का अर्थ देता है", इसलिए इसे ऊपर परिभाषा के संबंध में विलयित दृश्य और नियंत्रक कहा जा सकता है।
  2. मैं मानता हूं कि आपको नियंत्रक और मॉडल (फिर उपर्युक्त परिभाषा के संबंध में) विलय करने के लिए मजबूर होना होगा।
  3. मैं फिर से सहमत हूं। मॉडल केवल एप्लिकेशन डोमेन के डेटा का प्रबंधन करना चाहिए। यही वह है जिसे वे "डेटा" कहते हैं। जाहिर है, उदाहरण के लिए पंक्तियों और स्तंभों से निपटने के लिए आमतौर पर हमारे अनुप्रयोग डोमेन से कुछ लेना देना नहीं है।

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


मुझे नहीं पता कि मैंने कभी क्लास मैनेजर नाम दिया है, इसलिए मैं इसे छोड़ दूंगा।

मेरे लिए नियंत्रक कुछ नियंत्रित या निर्णय ले रहा है कि कुछ (सिग्नल, संदेश, ..) कहाँ जाना चाहिए।

सेवा एक इंटरफेस (और उस इंटरफ़ेस का कार्यान्वयन) है जो आमतौर पर सिस्टम या उप-प्रणाली की सीमा पर कुछ कार्यक्षमता प्रदान करती है। यथासंभव कार्यान्वयन विवरण छुपाता है।