2009-02-27 10 views
10

रॉबर्ट मार्टिन कहते हैं: "कक्षा बदलने के लिए एक से अधिक कारण कभी नहीं होना चाहिए"

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

क्या हमें व्यूमोडेल कक्षा के मामले में एसआरपी सिद्धांत के बारे में चिंता करनी चाहिए या नहीं?
एमवीवीएम में व्यूमोडेल कैसे बनाया जाए, एकल जिम्मेदारी सिद्धांत का उल्लंघन न करें?

उत्तर

18

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

यह कहा गया कि, यदि व्यूमोडेल बड़ा हो जाता है, तो हो सकता है कि आप दृश्यता को बेहतर बनाने और दृश्यों और दृश्य मॉडल को प्रबंधित करने के लिए दृश्य को कई सबव्यू में विभाजित करने के बारे में सोच सकें।

0

हां, लेकिन इसका मतलब यह नहीं है कि खराब डिजाइन आपको इसमें मजबूर नहीं कर सकता है।

2

मैं gcores से सहमत हूं।

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

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

0

मैं मानता हूं कि ब्लूटूथ और जटिलता को कम करने के लिए कई दृश्यों के साथ कई दृश्यों में अपनी स्क्रीन को विभाजित करना आवश्यक है। यहां एक और पैटर्न है जिसे मैंने एमवीवीएम का उपयोग करके एसआरपी में चिपकने में मदद करने के लिए नियोजित किया है:

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

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

  • कोई संबंधित समस्या नहीं^_^