संयोगवश, मैं एक WinForms परियोजना पर काम कर रहा हूं जो MVC के बाद बनाई गई है। मैं इसे एक सटीक उत्तर नहीं कहूंगा, लेकिन मैं अपने समग्र डिजाइन की व्याख्या करूंगा और उम्मीद है कि यह आपको अपने स्वयं के साथ आने में मदद कर सकता है।
इस परियोजना को शुरू करने से पहले मैंने जो रीडिंग की थी, उसके आधार पर इसे लागू करने का कोई "सही" तरीका नहीं है। मैंने सरल OOP और MVC डिजाइन सिद्धांतों का पालन किया और बाकी का परीक्षण और त्रुटि थी क्योंकि मैंने वर्कफ़्लो विकसित किया था।
क्या MVC इस उपयोग के मामले के लिए केवल एक अनुपयुक्त वास्तुकला है?
नहीं ..? उस प्रश्न का सीधा उत्तर देने के लिए आपके प्रश्न में पर्याप्त संदर्भ नहीं है। आप पहले स्थान पर एमवीसी का उपयोग क्यों कर रहे हैं? आपकी परियोजना की गैर-कार्यात्मक आवश्यकताएं क्या हैं? क्या आपका प्रोजेक्ट बहुत UI भारी होने जा रहा है? क्या आप सुरक्षा के बारे में अधिक परवाह करते हैं और यह एक स्तरित वास्तुकला है? आपकी परियोजना के मुख्य घटक क्या हैं? शायद प्रत्येक घटक को एक अलग डिज़ाइन पैटर्न की आवश्यकता होती है। पता करें कि आप पहली बार में इस डिज़ाइन पैटर्न का उपयोग क्यों करना चाहते हैं और आप अपने प्रश्न का उत्तर दे सकते हैं;)
एमवीसी का उपयोग करने के लिए मेरा कारण: मेरी राय में समझने के लिए इसका काफी सरल डिजाइन पैटर्न और मेरा डिजाइन उपयोगकर्ता इंटरैक्शन पर बहुत अधिक आधारित है। जिस तरह से एमवीसी डेवलपर को चिंताओं को अलग करने की अनुमति देता है वह मेरे आवेदन के लिए भी पर्याप्त है। यह मेरा कोड बनाता है बहुत अधिक maintainable और परीक्षण योग्य।
मुझे यह भी लगता है कि मैं हाइब्रिड डिज़ाइन का अधिक उपयोग कर रहा हूं। आमतौर पर, सॉफ्टवेयर इंजीनियरिंग में प्रस्तुत आदर्श अवधारणा वास्तव में व्यवहार में नहीं निकलती है। आप अपनी परियोजना की जरूरतों के अनुरूप डिजाइन को संशोधित कर सकते हैं। सही या गलत क्या है, इसको पकड़ने की जरूरत नहीं है। सामान्य प्रथाएं हैं, लेकिन जब तक आप खुद को पैर में गोली नहीं मारते, तब तक नियम हमेशा मुड़े या टूट सकते हैं।
मेरे कार्यान्वयन की शुरुआत एक उच्च स्तरीय डिजाइन से हुई जिसने मुझे इस बात का विचार दिया कि मुझे किन घटकों की आवश्यकता होगी। इस तरह से शुरू करने और आर्किटेक्चर में अपने तरीके से काम करने के लिए यह सबसे अच्छा है। यहाँ परियोजना के लिए पैकेज आरेख है (StarUML में बनाया गया है):
प्रेजेंटेशन लेयर को छोड़कर हर एक परत को मैसेजिंग सिस्टम पर निर्भर करता है। यह एक आम "भाषा" है जो उन परतों की निचली परतों और उप प्रणालियों का उपयोग एक दूसरे के साथ संवाद करने के लिए करती है। मेरे मामले में, यह ऑपरेशनों पर आधारित एक सरल गणना थी जिसे निष्पादित किया जा सकता है। जो मुझे अगले बिंदु पर लाता है ...
अपने कार्यान्वयन के आधार के रूप में संचालन या आदेशों के बारे में सोचें। आप अपने आवेदन को क्या करना चाहते हैं? इसे सबसे बुनियादी कार्यों में तोड़ दें। उदाहरण के लिए: CreateProject, WriteNotes, SaveProject, LoadProject आदि GUI (या फॉर्म क्लासेस) कुछ ईवेंट (जैसे एक बटन प्रेस) होने वाले हैं। हर ऑपरेशन की एक नियंत्रक विधि होती है। इस मामले में Exit जैसा कुछ बहुत सरल है। आवेदन केवल फॉर्म क्लास से बंद किया जा सकता है। लेकिन क्या मुझे लगता है कि मैं पहली बार कुछ एप्लिकेशन डेटा को एक फ़ाइल में जारी रखना चाहता था? मैं अपने बटन प्रेस विधि के भीतर संबंधित नियंत्रक वर्ग से "सेव" विधि को कॉल करूंगा।
वहां से, नियंत्रक सेवा वर्गों से संचालन के सही सेट को कॉल करेगा। मेरे आवेदन में सेवा वर्ग डोमेन परत के लिए एक अंतरफलक के रूप में कार्य करते हैं। वे नियंत्रक विधि कॉल (और इस प्रकार जीयूआई) से प्राप्त इनपुट को मान्य करेंगे और डेटा मॉडल में हेरफेर करेंगे।
एक बार सत्यापन और संबंधित ऑब्जेक्ट हेरफेर पूरा हो जाने के बाद, सेवा विधि नियंत्रक को एक संदेश कोड लौटाएगी। उदाहरण के लिए, MessageCodes.SaveSuccess। नियंत्रक और सेवा वर्ग दोनों डोमेन ऑब्जेक्ट्स और / या संचालन के सामान्य सेट पर आधारित थे जिन्हें एक साथ समूहीकृत किया जा सकता है।
उदाहरण के लिए: FileMenuController(ऑपरेशन: न्यूप्रोजेक्ट, सेवप्रोजेक्ट, लोडप्रोजेक्ट) -> ProjectServices(क्रिएटप्रोजेक्ट, पर्सिस्टप्रोजेक्टटॉइफाइल, लोडप्रोजेक्टफ्रेमफाइल)। Projectआपके डेटा मॉडल में एक डोमेन वर्ग कहां होगा। मेरे मामले में नियंत्रक और सेवा वर्ग स्थिर तरीकों के साथ गैर-तत्काल कक्षाएं थे।
फिर, नियंत्रक ऑपरेशन को संयुक्त राष्ट्र / सफलतापूर्वक पूरा करने के रूप में पहचानता है। अब, नियंत्रक की अपनी संदेश प्रणाली है जिसे वह प्रस्तुति परत के साथ बातचीत करने के लिए उपयोग करता है, इसलिए सेवा और प्रस्तुति परतों के बीच दोहरी निर्भरता है। इस स्थिति ViewStateमें ViewModelsपैकेज में बुलाया गया एक वर्ग हमेशा नियंत्रक द्वारा जीयूआई में वापस आ जाता है। इस स्थिति में जानकारी शामिल है: " क्या वह राज्य है जिसने आपने एप्लिकेशन को मान्य करने का प्रयास किया है? ", " आपके द्वारा किए गए ऑपरेशन के बारे में एक मानवीय पठनीय संदेश और यह सफल क्यों हुआ (त्रुटि संदेश) और एक ViewModelवर्ग " नहीं था ।
ViewModelवर्ग डोमेन परत से संबंधित डेटा कि जीयूआई दृश्य को अपडेट करें का उपयोग करेगा शामिल हैं। ये दृश्य मॉडल डोमेन कक्षाओं की तरह दिखते हैं लेकिन मेरे मामले में मैंने बहुत पतली वस्तुओं का उपयोग किया है । मूल रूप से उनके पास बहुत अधिक व्यवहार नहीं है, बस आवेदन के निचले स्तर की स्थिति के बारे में जानकारी रिले करें। दूसरे शब्दों में, मैं अपनी डोमेन कक्षाओं को प्रस्तुति परत पर देने के लिए कभी नहीं जा रहा हूँ । यही कारण है कि Controllersऔर Servicesपैकेज सर्विस लेयर को दो भागों में विभाजित करते हैं। नियंत्रक कभी भी डोमेन कक्षाएं नहीं संभालेंगे या अपने राज्य को मान्य नहीं करेंगे। वे बस एक सीमा के रूप में कार्य करते हैं GUI प्रासंगिक डेटा को डोमेन प्रासंगिक डेटा में सेवाओं का उपयोग कर सकते हैं और इसके विपरीत। कंट्रोलर में सर्विस लॉजिक को शामिल करने से बहुत वसा पैदा होगी नियंत्रकों, जिन्हें बनाए रखना कठिन है।
मुझे उम्मीद है कि यह आपको एक प्रारंभिक बिंदु देता है।