एमवीसी - सेट/प्राप्त सदस्यों को छोड़कर मॉडल वर्ग में कौन सी विधियां होनी चाहिए?

Question

तरीके कि मॉडल वर्ग सदस्य ही पर हेरफेर कर मॉडल या नियंत्रक में पर लागू किया जाना चाहिए? क्या यह इस हेरफेर के "भारी" पर निर्भर करता है?

"मैनिपुलेशन" मेरा मतलब है - एक वर्ग सदस्य प्राप्त करें, उस पर एक लंबी गणना करें और उसके बाद इस वर्ग से संबंधित एक और मूल्य लौटाएं।

उदाहरण के लिए - Board class जिसमें सेल मैट्रिक्स सदस्य है, अब मैं एक विधि को कार्यान्वित करना चाहता हूं जो सभी सेल को विशिष्ट सेल स्थान के अनुसार वापस कर दे। उपरोक्त को लागू करने के लिए कौन जिम्मेदार है?

यदि यह प्रश्न किसी अन्य स्टैक एक्सचेंज क्यूए से संबंधित है तो यह पद वितरित करने के लिए स्वागत किया जाएगा।

Answer 1

जिसे आप "मॉडल" कहते हैं, वास्तव में domain objects हैं। एमवीसी में वास्तविक मॉडल सिर्फ एक परत है, ठोस चीज नहीं है।

अपने विशेष उदाहरण में, Board में ऐसी कोई विधि होनी चाहिए जो इस सूची को लौटा दे। मुझे लगता है कि आप वास्तव में इसे प्राप्त कर रहे हैं क्योंकि आपको तब उन कोशिकाओं के साथ और अधिक बातचीत करने की आवश्यकता है।

यह वह जगह है जहां मॉडल परत के भीतर services खेलने के लिए आता है। यदि आप उनका उपयोग करते हैं, तो वे मॉडल परत का बाहरी हिस्सा हैं और इसमें अनुप्रयोग तर्क शामिल हैं - विभिन्न डोमेन ऑब्जेक्ट्स और दृढ़ता के बीच बातचीत (आमतौर पर data mappers या units of work) और डोमेन ऑब्जेक्ट्स के बीच बातचीत।

मान लें कि आप एक गेम बना रहे हैं, और आप और खिलाड़ी प्रदर्शन करते हैं और एओई हमले करते हैं। नियंत्रक सेवा की पकड़ लेता है, जो इस कार्यक्षमता के लिए ज़िम्मेदार है और कमांड भेजता है: इस प्लेयर ने इस दिशा में एओई का लक्ष्य रखा है, इसे करें।

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

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

डोमेन ऑब्जेक्ट में केवल उन्हीं विधियां होनी चाहिए, जो उनके राज्य से निपटती हैं।

Answer 2

अपने नियंत्रकों को पतला रखें, उन्हें बहुत कुछ न करने दें, यह ऑब्जेक्ट ओरिएंटेड डिज़ाइन के लिए सॉलिड में एकल जिम्मेदारी सिद्धांत के साथ संरेखित है। यदि आपके पास वसा नियंत्रक हैं, तो वे परीक्षण और रखरखाव करने में कठोर हो जाते हैं।

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

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

इसके अतिरिक्त, रूबी ऑन रेल्स समुदाय - जो कि अधिकांश एमवीसी ढांचे को प्रेरित करता है - ऐसा लगता है कि फैट मॉडल और स्कीनी नियंत्रक होने के आसपास एक प्रचार है।

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

Answer 3

मुझे लगता है कि एमवीसी के साथ इसका कोई संबंध नहीं है, और नियमित सॉफ्टवेयर इंजीनियरिंग के साथ बहुत कुछ करना है।

मैं व्यक्तिगत रूप से मॉडल में छोटी गणना करने में संकोच नहीं करता, लेकिन वसा मॉडल से बेहद सावधान रहूंगा।

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

जिस तरह से आप इसे लागू करते हैं वह आपके ऊपर है। आप या तो इस अलग वर्ग का उपयोग "शीर्ष स्तर" (बेहतर अवधि की कमी के लिए) वस्तु के रूप में कर सकते हैं, या मॉडल प्रतिनिधि का एक तरीका बना सकते हैं, ताकि आप इसका उपयोग कर रहे तथ्य को छिपाने के लिए कर सकें। मैं शायद बाद के लिए जाना होगा।

सब कुछ बहस योग्य है, हालांकि।प्रतीत होता है कि एमवीसी सही तरीके से कैसे करें और उनकी बहन की राय अलग-अलग है।

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

Answer 4

सर्वोत्तम अभ्यास के अनुसार हमें केवल पहुंच प्राप्त करने के लिए परिकलित क्षेत्रों के लिए गुणों का उपयोग करना चाहिए। उदाहरण सार्वजनिक डबल टोटलकोस्ट { प्राप्त करें { इसे वापस करें। रोल.कोस्ट * कुलहोर; } }