"ब्रिज" पैटर्न (टू-वे ब्रिज) या MVC का सही उपयोग -> "बिजनेस एंटिटी - विज़ुअलाइज़ेशन - कंट्रोलर"

प्रागितिहास

लेख पुल / ब्रिज डिजाइन पैटर्न का दुरुपयोग, जैसा कि हुआ, दर्शकों को दो में विभाजित किया गया। फिर मैंने सोचा, कह रहा है कि A ने B नहीं कहा, यह सही नहीं होगा। नहीं, मैं अपने शब्दों को अस्वीकार नहीं करता हूं, लेकिन मैंने पाया कि मैंने "ब्रिज" पैटर्न का उपयोग कहां और कैसे किया। क्योंकि यह भी गलत समझा गया है, ऐसा लगता है कि वैकल्पिक नाम "Descriptor / body" कम भ्रामक है।

तो कहाँ है? यह एमवीसी (मॉडल / दृश्य / नियंत्रक) की अवधारणा का उपयोग करने के मेरे एनालॉग में निकला।

इसलिए, सबसे पहले मैं अपनी विविधता "बिजनेस एंटिटी - विज़ुअलाइज़ेशन - कंट्रोलर" पेश करूंगा। मैंने इसे पहले ही लिखा था, लेकिन मुझे लगता है कि बहुत कम लोग इससे परिचित हैं। और फिर हम देखेंगे कि "राइट ब्रिज" कहाँ है।

PS मुझे यहाँ विश्वास का श्रेय दिया गया था, और मैंने फ्लाईवेट पैटर्न में सुधार करने पर एक और लेख लिखने का बीड़ा उठाया - मैंने एक रिपोर्ट लिखी ।



विज़ुअलाइज़ेशन और व्यावसायिक तर्क का पृथक्करण

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

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

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

लेकिन कभी-कभी एक मॉडल (तथाकथित निष्क्रिय मॉडल) वास्तव में केवल डेटा के रूप में समझा जाता है (गुण, उन तक पहुंच के तरीके, डेटाबेस से उन्हें प्राप्त करना) बिना व्यावसायिक तर्क के, फिर जब आप इसे अलग करते हैं, तो ऐसा मॉडल अपने आप बेकार हो जाता है। आइए हम शास्त्रीय निष्क्रिय मॉडल "मॉडल-व्यू-कंट्रोलर" की तर्कसंगतता को सत्यापित करते हैं, ज्यादातर मामलों में, यदि आप प्रस्तुति और नियंत्रक ऑब्जेक्ट नहीं बनाते हैं, तो शेष मॉडल ऑब्जेक्ट पूरी तरह से "लकवाग्रस्त" रहेगा, अर्थात यह गैर-कार्यात्मक रहेगा। इस प्रकार, हम देखते हैं कि इस मॉडल में स्वतंत्रता की घोषणा एक कल्पना है।

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

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

अब आइए मॉडल-व्यू-कंट्रोलर मॉडल के लिए घोषणा देखें:

जबकि दृश्य और नियंत्रक मॉडल पर निर्भर करते हैं, मॉडल दृश्य या नियंत्रक पर निर्भर नहीं करता है। यह पृथक्करण की एक प्रमुख विशेषता है, जो आपको दृश्य प्रतिनिधित्व की परवाह किए बिना मॉडल के साथ काम करने की अनुमति देता है, और इसलिए आवेदन के व्यावसायिक तर्क के साथ।

लेकिन दृश्य प्रतिनिधित्व से मॉडल की स्वतंत्रता के अलावा, इसके विपरीत अक्सर आवश्यक होता है। आपके पास मॉडल से दृश्य प्रतिनिधित्व की स्वतंत्रता भी होनी चाहिए। और यह MVC में परिभाषा द्वारा असंभव है।

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

क्या यह आपको कम से कम अजीब नहीं लगता? यह पता चलता है कि कोई व्यावसायिक संस्था यह तय नहीं कर सकती है कि वह स्वयं कैसे कल्पना कर सकता है, या यह कल्पना भी कर सकता है। इसके अलावा, उपयोगकर्ता (इस मामले में, एप्लिकेशन डेवलपर) को विज़ुअलाइज़ेशन ऑब्जेक्ट या नियंत्रक बनाना होगा, और कुछ अजीब तरीके से किसी व्यवसाय इकाई के साथ विज़ुअलाइज़ेशन या नियंत्रक के माध्यम से काम करना होगा। हालांकि स्वीकार्य दृश्य की आवश्यकता नहीं हो सकती है।

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

लेकिन हमें अभी भी मौलिक स्थिति को पूरा करने की आवश्यकता है:

विज़ुअलाइज़ेशन वर्गों में केवल तर्क है जो उपयोगकर्ता इंटरफ़ेस के साथ काम करने के लिए आवश्यक है। और व्यवसाय इकाई वर्ग में विज़ुअलाइज़ेशन कोड नहीं होता है, लेकिन उनमें सभी व्यावसायिक तर्क होते हैं।

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

C # विज़ुअलाइज़ेशन के लिए नवीनतम WPF तकनीक का उपयोग करता है, जो एक बाध्यकारी तंत्र प्रदान करता है। इसलिए, यह केवल यह इंगित करने के लिए रहता है कि कौन से गुण परस्पर जुड़े होंगे। और दुविधा पैदा होती है - यह किस वस्तु में किया जाना चाहिए? यदि यह व्यवसाय इकाई में लिखा गया है, तो हम उल्लंघन करते हैं, व्यापार इकाई के नियम वर्गों में विज़ुअलाइज़ेशन कोड शामिल नहीं है, यदि यह विज़ुअलाइज़ेशन वर्ग में लिखा गया है, तो हम नियम का उल्लंघन करते हैं विज़ुअलाइज़ेशन वर्गों में केवल तर्क है जो उपयोगकर्ता इंटरफ़ेस के साथ काम करने के लिए आवश्यक है। मॉडल-व्यू-कंट्रोलर मॉडल में, यह अक्सर विज़ुअलाइज़ेशन क्लास में निर्दिष्ट होता है।

लेकिन हम अलग तरह से काम करेंगे। तीसरे को पेश करने के कारणों में से एक, पूरी तरह से निरर्थक वर्ग - नियंत्रक, ठीक वही है जो ऊपर इंगित किया गया है। लेकिन पहले, आइए यह स्पष्ट करने का प्रयास करें कि नियंत्रक क्या है, और जब यह बनाया जाता है। "बिजनेस एंटिटी - विज़ुअलाइज़ेशन - कंट्रोलर" मॉडल में नियंत्रक अनिवार्य रूप से एक व्यावसायिक इकाई और इसके विज़ुअलाइज़ेशन के बीच बातचीत का एक प्रोटोकॉल है। उसी समय, जब कोई व्यावसायिक इकाई यह निर्धारित करती है कि उसे किसी तरह से कल्पना करने की आवश्यकता है, तो यह एक निश्चित विज़ुअलाइज़ेशन क्लास का एक ऑब्जेक्ट चुनता है और बनाता है, जिसके बाद यह एक या एक अन्य इंटरैक्शन प्रोटोकॉल बनाता है - एक नियंत्रक। उसी समय, नियंत्रक बनाते समय, वह उसे स्वयं के लिए और चयनित विज़ुअलाइज़ेशन के लिए दो लिंक पास करती है। उसके बाद, व्यापार इकाई सैद्धांतिक रूप से (यह पूरी तरह से प्राप्त करने के लिए व्यावहारिक रूप से फिर भी मुश्किल हो सकती है) अब विज़ुअलाइज़ेशन ऑब्जेक्ट या स्वयं नियंत्रक के साथ काम नहीं करना चाहिए, जिससे पूर्ण स्वतंत्रता सुनिश्चित हो सके।

यह पता चला है कि नियंत्रक प्रारंभ के दौरान बाध्यकारी को निर्धारित करता है, दृश्य फ़ील्ड को व्यावसायिक इकाई के क्षेत्रों के साथ जोड़ता है, जिसके बाद औपचारिक रूप से ये दो विज़ुअलाइज़ेशन ऑब्जेक्ट्स और व्यावसायिक इकाइयां चयनित प्रोटोकॉल के अनुसार सिंक्रनाइज़ किए जाते हैं, लेकिन उनके बीच कोई अन्य इंटरैक्शन नहीं है। इस दृष्टिकोण को पारदर्शी संचार कहा जाता है, अर्थात्, कोई प्रत्यक्ष बातचीत नहीं है, लेकिन प्रोटोकॉल के अनुसार केवल बातचीत होती है - कोड जो नियंत्रक में पंजीकृत है।

यदि आप एक अलग प्रोग्रामिंग भाषा का उपयोग करते हैं, और बाइंडिंग का उपयोग करने का कोई तरीका नहीं है, तो आप इसे डुप्लिकेट अवलोकन डेटा [1] नामक एक रिफैक्टिंग तकनीक के साथ बदल सकते हैं।

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

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

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

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

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

इस पाठ को समझना मुश्किल हो सकता है। एक अच्छा व्यक्ति है जिसने मेरी सहायता के साथ लिखा है, शायद मेरे विचार का अधिक समझदार वर्णन। कोड उदाहरणों के साथ।

नियंत्रक पुल है

यदि आप यहां "पुल" की तलाश करते हैं, तो यह पता चलता है कि नियंत्रक के पास दो "निकायों" के लिए दो लिंक हैं। एक "बिजनेस एंटिटी" पर, दूसरा "विज़ुअलाइज़ेशन" पर। वह यहाँ क्यों समाप्त हो गया, अगर मैंने पहले लेख में तर्क दिया, "अमूर्त और कार्यान्वयन में अलगाव" हानिकारक है।

और सभी क्योंकि नियंत्रक काफी कार्यान्वयन नहीं है, और काफी अमूर्त नहीं है। अमूर्त और कार्यान्वयन यहाँ एक साथ हैं क्योंकि यह एक "व्यावसायिक इकाई" में होना चाहिए। लेकिन विज़ुअलाइज़ेशन और व्यावसायिक तर्क के बीच संचार का एक निश्चित तर्क नियंत्रक में निकाला जाता है। संचार का यह तर्क पुल पर लाने के लिए अच्छा है। संक्षेप में, विज़ुअलाइज़ेशन "व्यापार इकाई" के कुछ कार्यान्वयन का हिस्सा है, लेकिन यह बहुत खास है। और जब हम इसे अलग करते हैं, तो अलग-अलग पदानुक्रमों में "उपयोगकर्ता इंटरफ़ेस" और "बिजनेस लॉजिक" को अलग-अलग विकसित करना बहुत अच्छा होता है। लेकिन उन्हें नियंत्रक के माध्यम से कनेक्ट करें। यह ब्रिज पैटर्न का सही उपयोग है। लेकिन यह "दो-तरफ़ा ट्रैफ़िक वाला ब्रिज" की तरह है, एक तरफ हम व्यावसायिक तर्क (ठोस) और दूसरी ओर "विज़ुअलाइज़ेशन" पर चलते हैं।