मुझे इस Passive Screen पैटर्न के साथ बड़ी सफलता मिली।
मेरी राय में, पारंपरिक एमवीसी आर्किटेक्चर की बड़ी समस्या यह है कि लोग फॉर्म वर्गों में बहुत अधिक तरीके से काम करते हैं। इससे आपको मैन्युअल परीक्षण की मात्रा बढ़ जाती है।
संकलित करने के बाद आप जितना अधिक स्वचालित परीक्षण कर सकते हैं, उतनी अधिक बग आप अपने डेस्क पर पकड़ लेंगे। एक जटिल अनुप्रयोग में, मामूली परिवर्तनों से दुष्प्रभाव भी अक्सर होते हैं।
इसे हल करने की चाल एक नियंत्रक असेंबली बना रही है जो फॉर्म असेंबली (या EXE) संदर्भ है। प्रत्येक फॉर्म में असेंबली में एक समान वर्ग है। एक बटन पर क्लिक करने से ThisForm.ThisButton(<args>) पर कॉल होगा जो आपके ढांचे में वस्तुओं को कम करेगा। प्रत्येक फॉर्म एक इंटरफेस लागू करता है ताकि, यदि नियंत्रक वर्ग को फॉर्म से अतिरिक्त जानकारी की आवश्यकता है, तो इसे पुनर्प्राप्त करने के लिए एक इंटरफ़ेस है।
फिर अपने unit testing के लिए आप डमी कक्षाओं को कार्यान्वित करने और नियंत्रक कक्षाओं को जानकारी फ़ीड करने के लिए डमी कक्षाओं को कार्यान्वित करके जटिल संचालन करने वाले ऑपरेटर का अनुकरण करते हैं। नियंत्रक वर्गों को किसी भी अलग नहीं पता है क्योंकि डमी वर्ग सभी अपेक्षित इंटरफेस को लागू करते हैं।
एक महत्वपूर्ण अपवाद है और यह मामूली संवाद के लिए है। उन संवादों के लिए जिनके पास कुछ चेक बॉक्स हैं, मुझे लगता है कि यह संगठन अधिक है। मैं command pattern बहुत उपयोग करता हूं। तो असेंबली में जहां मैं कमांड ऑब्जेक्ट्स को परिभाषित करता हूं, मैंने उस कमांड से जुड़े सरल संवाद को रखा है। यह उपचार आपको प्राप्त करने के लिए एक संवाद कितना आसान होना चाहिए।
मुझे निम्नानुसार मेरे अनुप्रयोगों को ढांचा बनाना पसंद है।
उपयोगिता - यह एक विधानसभा सामान मैं हर समय का उपयोग किया है - गणित काम करता है, फ़ाइल समारोह, आदि
वस्तुओं - यह विशिष्ट वस्तुओं मैं इस आवेदन के लिए उपयोग कर रहा हूँ है।
UIFramework - यह सभी रूपों और नियंत्रक इंटरफेस को परिभाषित करता है।
कमांड - इसमें सभी कमांड ऑब्जेक्ट्स हैं जो मेरी एप्लिकेशन ऑब्जेक्ट्स में हेरफेर करते हैं।
यूआई - वस्तुओं है कि नियंत्रक इंटरफेस
EXE लागू - फार्म कि प्रपत्र इंटरफ़ेस को लागू और नियंत्रक वस्तुओं कहता है।
स्रोत
2008-11-05 14:12:37