डेल्फी में उपयोगकर्ता इंटरफ़ेस कार्यान्वयन के लिए एमवीसी दृष्टिकोण। भाग 3. वस्तुएँ

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


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

ऐसा करने के लिए, मैं ट्यूसर वर्ग का विस्तार इस प्रकार करूंगा:

TUser = class private ... FOnChangeRoles: TNotifyEvent; protected ... procedure DoChangeRoles; public ... property OnChangeRoles: TNotifyEvent read FOnChangeRoles write FOnChangeRoles; end; procedure TUser.DoChangeRoles; begin if Assigned(FOnChangeRoles) then FOnChangeRoles(Self); end; 

मैंने TUser ऑब्जेक्ट में एक साधारण नोटिफ़िकेशन ईवेंट जोड़ा, जो हमें कर्मचारी भूमिकाओं की सूची में बदलाव के बारे में सूचित करेगा। इस स्थिति में, TUser वर्ग का SetRoles तरीका निम्न रूप लेगा:

 procedure TUser.SetRoles(Value: TIntList); begin if not SameIntLists(Roles, Value) then begin Roles := Value; DoChange; //   end; end; 

जब तक TUser वर्ग OnChangeRoles ईवेंट ओवरराइड नहीं किया जाता है (FOCChangeRoles डिफ़ॉल्ट रूप से शून्य है), DoChangeRoles को कॉल करने से कुछ नहीं होता है। किसी तरह इस घटना का जवाब देने में सक्षम होने के लिए, आपको ट्यूसर ऑब्जेक्ट के लिए उपयुक्त हैंडलर असाइन करने की आवश्यकता है।
इस हैंडलर को फॉर्म क्लास में लाना तर्कसंगत है:

 procedure TfmUserRights.ProcRolesChanged(Sender: TObject); begin FillUserRoles; end; 

अब हमें TUser वर्ग की वस्तुओं पर इस ईवेंट हैंडलर को लटकाना होगा:

 procedure TfmUserRights.FillUsers; var i: Integer; begin FUsers.Free; //   ,    FUsers := GetUsers; for i := 0 to FUsers.Count-1 do FUsers[i].OnChangeRoles := ProcRolesChanged; ... end; 

बस इतनी सी बात है :)। अब, जब किसी ऑब्जेक्ट की भूमिकाओं को बदलते हैं, तो OnChangeRoles ईवेंट आग लगा देगा, जो निर्दिष्ट हैंडलर FillUserRoles को कॉल करेगा और GUI को अपडेट करेगा (भूमिकाओं की सूची फिर से भरें)। इन परिवर्तनों के साथ, पिछले लेख का कोड सही ढंग से काम करेगा।

क्या यह बेहतर हो सकता था?

1) पिछले लेख के संदर्भ में, मुझे केवल भूमिकाओं की सूची में बदलाव के लिए प्रतिक्रिया करने की आवश्यकता थी, इसलिए मैंने एक विशिष्ट घटना को लाया जो केवल ट्यूसर वर्ग के रोल्स क्षेत्र में परिवर्तन के प्रति प्रतिक्रिया करता है। अक्सर, आपको किसी वस्तु में नहीं, बल्कि कई (या शायद सभी) फ़ील्ड में परिवर्तनों का जवाब देने की आवश्यकता होती है। इस मामले में, इस घटना को शुरू करना बेहतर था, न कि OnChangeRoles, लेकिन बस OnChange, हालांकि इस मामले में हैंडलर को न केवल भूमिकाओं की सूची का पुनर्निर्माण करना चाहिए, बल्कि उस समय विंडो में प्रदर्शित की जाने वाली किसी भी अन्य उपयोगकर्ता जानकारी को भी अपडेट करना चाहिए। तदनुसार, DoChange कॉल केवल SetRoles में ही नहीं, बल्कि TUser ऑब्जेक्ट के बचे हुए क्षेत्रों के बसने वालों में भी स्थित होगी, जिनके परिवर्तन हम ट्रैक करना चाहेंगे। और यहां मुख्य कार्य ऑब्जेक्ट के लिए एक नया फ़ील्ड जोड़ते समय इस DoChange कॉल को जोड़ना नहीं भूलना है, क्योंकि यह लंघन बहुत आसान है।
2) सुरक्षित प्रोग्रामिंग के सिद्धांतों के आधार पर, यदि हम एक ईवेंट हैंडलर को पंजीकृत करते हैं (जैसा कि वे कहते हैं, "किसी ईवेंट को सब्सक्राइब करें), तो हमें इस सब्सक्रिप्शन (" अपंजीकृत "प्रोसेसर) को हटाना होगा, अर्थात OnChangeRoles को उसकी मूल स्थिति में या सबसे खराब शून्य पर लौटाएं। क्या यह आवश्यक है कि इस मामले को प्रत्येक मामले में व्यक्तिगत रूप से तय किया जाए। सबसे पहले, यह TUser वस्तुओं के जीवनकाल और आकार की वस्तु के अनुपात पर निर्भर करता है। यदि फॉर्म TUser से अधिक समय तक रहता है, तो, सिद्धांत रूप में, पुनः पंजीकरण की आवश्यकता नहीं है। यदि, इसके विपरीत, फॉर्म नष्ट होने के बाद भी TUser जीवित रह सकता है, तो निश्चित रूप से आपको OnDestroy में फॉर्म में कुछ दर्ज करना होगा

  for i := 0 to FUsers.Count-1 do FUsers[i].OnChangeRoles := nil; 

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

माना विधि को एक ग्राहक के साथ सूचनाओं की सदस्यता माना जा सकता है। हालाँकि, यह अभी तक सूचनाओं की पूर्ण सदस्यता नहीं है। सूचनाएं अच्छी हैं क्योंकि आप जितने चाहें उतने ग्राहक बन सकते हैं। अब हम देखेंगे कि यह कैसे किया जाता है। चलो दूसरे काम पर जाते हैं।

मल्टी-सब्सक्राइबर अधिसूचनाएं

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

 TUsersMngr = class public procedure SaveUser(aUser: TUser); end; 

सभी विंडो जिसमें कर्मचारी से संबंधित कोई भी जानकारी प्रदर्शित हो सकती है, SaveUser कॉल का जवाब देना चाहती है। इस स्थिति में, TUserMngr वर्ग को उन सभी हैंडलर के लिंक संग्रहीत करने होंगे जो कर्मचारी सेव इवेंट के लिए सदस्यता ले सकते हैं:

 TUsersMngr = class private FNotifiers: array of TNotifyEvent; public procedure RegChangeNotifier(const aProc: TNotifyEvent); procedure UnregChangeNotifier(const aProc: TNotifyEvent); function NotifierRegistered(const aProc: TNotifyEvent): Boolean; end; 

इस कार्यक्षमता के साथ, आप आसानी से किसी भी विंडो से अपनी रुचि की वस्तुओं के परिवर्तनों की सदस्यता ले सकते हैं:

 procedure TUsersListForm.FormCreate(Sender: TObject); begin ... UsersMngr.RegChangeNotifier(ProcUsersChanges); end; procedure TUsersListForm.FormDestroy(Sender: TObject); begin UsersMngr.UnregChangeNotifier(ProcUsersChanges); ... end; procedure TUsersListForm.ProcUsersChanged(Sender: TObject); begin RefillUsersList; end; 

अब जब हम समझ गए हैं कि इसका उपयोग कैसे किया जाएगा, हम सीधे अधिसूचना के क्षण में लौट आएंगे, अर्थात तब तक घटना शुरू हो जाती है:

 procedure TUsersMngr.SaveUser(aUser: TUser); begin if aUser.Changed then begin ... //   aUser   ... DoUserChangeNotify; //   end; end; procedure TUsersMngr.DoUserChangeNotify; var i: Integer; begin for i := 0 to High(FNotifiers) do FNotifiers[i](Self); end; 

अब, जब TUser ऑब्जेक्ट सहेजा जाता है, तो सभी प्रपत्रों को इस बारे में सूचित किया जाएगा कि क्या वे संबंधित ईवेंट की सदस्यता लेना नहीं भूलते हैं।

हैंडलर लॉकआउट

उपरोक्त कोड अच्छा है जब तक कि बड़ी संख्या में ऑब्जेक्ट सिस्टम में तुरंत दिखाई न दें। शायद सबसे अच्छा उदाहरण नहीं: कर्मचारियों के एक समूह को प्रशिक्षित किया गया था और उनमें से प्रत्येक को एक प्रमाण पत्र मिला था जो सभी के लिए समान था। हम सूची में 10 कर्मचारियों का चयन करते हैं, "प्रमाण पत्र जोड़ें" पर क्लिक करें। इसके बाद, UserMngr.Save के लिए कॉल इन 10 कर्मचारियों में से प्रत्येक के लिए होता है। इस स्थिति में, प्रत्येक कर्मचारी को बचाने के बाद, DoUserChangeNotify परिवर्तन घटना शुरू हो जाती है, जो सभी खुली खिड़कियों में कर्मचारी सूची के पुनर्निर्माण की ओर जाता है (और प्रत्येक पुनर्निर्माण डेटाबेस से या एप्लिकेशन सर्वर से कर्मचारी सूची का एक रिबूट भी होगा)। परिणामस्वरूप, 10 कर्मचारियों soooooooo के लिए परिवर्तन सहेजे जाएंगे और इसके अलावा हमें खुली एप्लिकेशन की खिड़कियों में बहुत सारे पलकें मिलेंगी (सूचियों को 10 बार फिर से बनाया जाएगा)। अब मैं इससे बचने का एक सरल तरीका बताऊंगा:

 TUsersMngr = class private FLock: Integer; FChanged: Boolean; public procedure BeginUpdate; procedure EndUpdate; end; procedure TUsersMngr.Create; begin ... FLock := 0; FChanged := False; end; procedure TUsersMngr.BeginUpdate; begin Inc(FLock); end; procedure TUsersMngr.EndUpdate; begin Assert(FLock > 0); Dec(FLock); if (FLock = 0) and Changed then DoUserChangeNotify(Self); end; 

अधिसूचना विधि भी बदल जाएगी:

 procedure TUsersMngr.DoUserChangeNotify; var i: Integer; begin if FLock > 0 then //      begin FChanged := True; // ,     Exit; end; FChanged := False; for i := 0 to High(FNotifiers) do FNotifiers[i](Self); end; 

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

इस प्रकार, कई वस्तुओं को बदलने के लिए कोड को अत्यधिक घटनाओं से आसानी से संरक्षित किया जा सकता है:

 UsersMngr.BeginUpdate; try for i := 0 to FSomeUsers[i] do UsersMngr.Save(FSomeUsers[i]); finally UsersMngr.EndUpdate; end; 

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

परिणाम

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

आपका दिन शुभ हो!

PS लेख के पिछले भागों के लिंक:
भाग 1. चेकमार्क।
भाग 2. सूचियाँ।