ओओ प्रश्न - मिश्रण नियंत्रक तर्क और व्यापार तर्क

Question

मुझे यकीन नहीं है कि मैं "मानक" शब्दों का उपयोग कर रहा हूं, लेकिन यह एक मूल ओओ प्रश्न है जिसे मैं हल करने की कोशिश कर रहा हूं।

मैं एक विंडोज़ फॉर्म कोडिंग कर रहा हूं। मैं फॉर्म इवेंट हैंडलर में तर्क नहीं चाहता हूं, इसलिए मैं वहां से एक कस्टम ऑब्जेक्ट पर कॉल करता हूं।

कस्टम ऑब्जेक्ट पर, तर्क के दो सेट हैं।

1. "नियंत्रक" तर्क, जो तय करता है कि क्या करने की आवश्यकता है और कब।
2. वास्तविक व्यापार तर्क जो करने की आवश्यकता है (उदाहरण के लिए एक नियंत्रण जो गणित संचालन करता है और परिणाम देता है, आदि)।

मेरा सवाल है, क्या ओओ आर्किटेक्चर इन दोनों को एक ही वस्तु में रखने की अनुमति देता है? या क्या उन्हें "नियंत्रक" ऑब्जेक्ट और "व्यावसायिक तर्क" ऑब्जेक्ट में विभाजित करने की अनुशंसा की जाती है? क्या इसके लिए एक डिज़ाइन पैटर्न है जिसका मुझे संदर्भ होना चाहिए?

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

Answer 1

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

Answer 2

नहीं, मैं नियंत्रकों में व्यावसायिक तर्क नहीं डालता हूं। मैं एक मध्यवर्ती सेवा परत जोड़ता हूं जिसे नियंत्रकों में इंजेक्शन दिया जाता है। सेवा को काम करने दें। नियंत्रक रूटिंग अनुरोधों और मार्शल प्रतिक्रियाओं के लिए हैं।

एक स्वच्छ सेवा परत में तर्क डालना "सेवा उन्मुख" है, भले ही आप वेब सेवाओं या डब्लूएसडीएल का उपयोग नहीं कर रहे हों। यदि आप नियंत्रक/दृश्य प्रौद्योगिकियों को बदलने का निर्णय लेते हैं तो इसमें अभी भी काम करने का अतिरिक्त लाभ है।

Answer 3

आप जो कर रहे हैं वह "वसा नियंत्रक" वास्तुकला का एक रूप है। इन दिनों सॉफ्टवेयर विकास पतली नियंत्रकों की तरफ बढ़ रहा है।

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

"Domain-Driven Design Quickly" देखें। यह निःशुल्क ई-पुस्तक एरिक इवांस की महत्वपूर्ण पुस्तक "डोमेन-संचालित डिजाइन" में शामिल अवधारणाओं के लिए एक संघनित परिचय है।

इन अवधारणाओं में शिक्षित होने से आपको यह समझने में मदद मिलनी चाहिए कि नियंत्रक या सेवा परत से व्यावसायिक तर्क को कैसे अलग किया जाए।

Answer 4

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

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