2009-12-15 13 views
6

मुझे लगता है कि एमवीपी में मॉडल वास्तव में क्या है इसके बारे में मेरा सिर नहीं लगता है।मॉडल व्यू प्रेजेंटर (एमवीपी) मॉडल क्या है?

यदि मेरे पास एक स्तरित आर्किटेक्चर प्रस्तुति/आवेदन/डोमेन/इन्फ्रास्ट्रक्चर है, तो मॉडल वास्तव में क्या है?

  1. डोमेन ऑब्जेक्ट्स निम्न परतों के माध्यम से पहुंचा?
  2. प्रस्तुति परत में परिभाषित एक अलग ऑब्जेक्ट जो UI पर मैप करता है और निचली परत से प्राप्त डेटा का उपयोग करता है?

यदि कोई व्यक्ति मेरी समझ को साफ़ कर सकता है तो मॉडल की क्या सराहना की जाएगी।

+1

शाह ... चिल्लाने की कोई ज़रूरत नहीं है। –

उत्तर

6

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

आपके स्तरित उदाहरण में, मॉडल ज्यादातर डोमेन परत में पाया जाएगा लेकिन यह एप्लिकेशन परत में भी हो सकता है।

मुझे लगता है कि आपको इसे समझने में कठिनाई हो रही है क्योंकि आप दो अलग-अलग वास्तुशिल्प पैटर्न, या एप्लिकेशन को देखने के तरीकों को गठबंधन करने की कोशिश कर रहे हैं, एन-टियर/एन-लेयर बनाम एमवीपी।

किसी भी समय मॉडल/व्यू दृष्टिकोण का उपयोग करने के लिए यह पूरी तरह से उचित (और काफी आम है) जबकि आपके आवेदन में लेयरिंग लागू करने के साथ ही।

शायद आपको उन पर ध्यान केंद्रित करने के लिए एक समय पर ध्यान देना चाहिए और फिर जब आप दोनों से अधिक परिचित हों तो उन्हें ओवरले करें।

+0

क्या आप कह रहे हैं कि ये दो वास्तुशिल्प पैटर्न अलग हैं और उन्हें संयुक्त नहीं किया जाना चाहिए? – David

+1

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

+0

@ डेविड, नहीं, ईमानदार होने के लिए मैंने अधिक सामान्य एमवीसी के लिए एमवीपी को गलत तरीके से पढ़ा है। जहां तक ​​मुझे पता है एमवीपी आपके यूआई के बारे में है। मुझे वास्तव में इन विभिन्न पैटर्न में मॉडल का पुन: उपयोग मिलता है। मॉडल के सबसे व्यापक रूप से सहमत definiton के लिए आपको मार्टिन फाउलर द्वारा एंटरपेज एप्लाइकेशन आर्किटेक्चर के पैटर्न पर एक नज़र डालना चाहिए। – Ash

4

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

यदि आपके एप्लिकेशन में पहले से ही डोमेन ऑब्जेक्ट्स हैं, तो यह बहुत अच्छा हो सकता है कि आप उन्हें अपने मॉडल के लिए उपयोग कर सकते हैं।

+0

जस्टिन यदि आप आवश्यकता के अनुरूप हैं तो आपका क्या मतलब है? – David

+0

"ज़रूरत के अनुरूप" से मेरा मतलब था कि यदि वे आपके विचारों में प्रस्तुत करने के लिए आवश्यक डेटा व्यक्त करते हैं। यदि नहीं, तो समस्या को आसानी से हल मॉडलों का उपयोग करके हल किया जा सकता है ... जो बहुत अधिक मॉडल हैं विशेष रूप से दृश्यों में प्रस्तुत करने के लिए डेटा व्यक्त करने के लिए। –

+0

इन दृश्य मॉडल बनाने के लिए कौन जिम्मेदार होगा? क्या मॉडल को वही देखा गया है जिसे मैंने स्क्रीन डीटीओ के रूप में संदर्भित किया है? – David

1

मॉडल डेटा है। यह डेटासेट्स में डेटाबेस से डेटा हो सकता है, या यह आपके पूरे व्यवसाय के क्षेत्र का प्रतिनिधित्व करने वाली वस्तुओं के साथ एक पूर्ण डोमेन मॉडल हो सकता है।

देखें यूआई है, चाहे वेब पेज या विंडोज एप्लिकेशन या मोबाइल डिवाइस एप्लिकेशन।

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

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

+0

क्या यह प्रस्तुतकर्ता है जो उदाहरण के लिए निर्धारित करेगा यदि मॉडल – David

+0

मॉडल के आसपास के कुछ तर्कों के आधार पर एक बटन सक्षम/अक्षम किया गया था, हां। मैं अवसर पर सभी चीजों को देखने के ऊपर नहीं हूं, जहां दृश्य के दो परस्पर निर्भर भाग हैं जिनके पास प्रस्तुतकर्ता या मॉडल के साथ कोई संबंध नहीं है। मुझे लगता है कि उस पर अंगूठे का सबसे अच्छा नियम यह है कि क्या किया जा रहा है * किसी भी * यूआई में किया जाना चाहिए (इस मामले में इसे प्रस्तुतकर्ता से किया जाना चाहिए) या यह विशेष प्रकार के यूआई के लिए विशिष्ट है या नहीं उपयोग (उदाहरण के लिए आप WinForms में कुछ करना चाहते हैं लेकिन WPF में नहीं)। –

2

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

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

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