EXpressApp फ्रेमवर्क (XAF) के स्मार्ट रूप। भाग 1

“रूपों से क्या आवश्यक है?” समीक्षा को पढ़ने के बाद, मैं यह बताना चाहता था कि कैसे “सार्वभौमिक, गतिशील रूप से बदलते हुए रूप” को हमारे फ्रेमवर्क में eXpressApp फ्रेमवर्क के LOB अनुप्रयोगों को जल्दी से बनाने के लिए व्यवस्थित किया जाता है।

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

[DomainComponent] public interface ICustomer : IOrganization, IAccount { } 

शुरुआत में वर्ड था ... या एक व्यावसायिक वस्तु!

बॉक्स से बाहर, रूपरेखा कई मुख्य प्रकार या "दृश्य" प्रदान करती है, जिसका उद्देश्य नाम से काफी हद तक स्पष्ट है:
• सूची दृश्य - व्यावसायिक वस्तुओं की एक सूची पेश करने के लिए कार्य करता है;
• डिटेल व्यू - वस्तु के बारे में विस्तृत जानकारी प्रस्तुत करने के लिए कार्य करता है;
• डैशबोर्ड दृश्य - कई अलग-अलग दृश्य दिखाने का कार्य करता है, अर्थात् एक कंटेनर है जो आम तौर पर व्यापारिक वस्तुओं के बारे में कुछ भी नहीं जानता है।

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

मुझे लगता है कि पर्याप्त सिद्धांत है, चलो ऊपर एक विशिष्ट उदाहरण के साथ प्रदर्शित करते हैं। सबसे पहले, ICustomer व्यापार इकाई बनाएं (सादगी के लिए, कक्षाओं के बजाय, मैं इंटरफेस या डोमेन घटकों का उपयोग करूंगा, जैसा कि हम उन्हें जानते हैं):

 [DomainComponent] public interface ICustomer : IOrganization, IAccount { } 

, जो कई घटकों से बना होगा:

 [DomainComponent] public interface IAccount { string Email { get; set; } string Password { get; set; } } [DomainComponent] public interface IPerson { string LastName { get; set; } string FirstName { get; set; } DateTime Birthday { get; set; } } [DomainComponent] public interface IOrganization { string Name { get; set; } IList<IPerson> Staff { get; } IPerson Manager { get; set; } } 

डेवलपर के लिए फ्रेमवर्क कितना आसान बनाता है, इसका आकलन करने के लिए, मैं आवेदन के पहले लॉन्च के बाद प्राप्त किया गया परिणाम दूंगा, जिसमें उपरोक्त उदाहरण से केवल व्यापारिक संस्थाएं शामिल हैं:





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

इसलिए, हमारे मामले में, केवल ICustomer व्यापार इकाई होने के नाते, कुछ ही मिनटों में मुझे बहुक्रियाशील विंडोज़ और वेब एप्लिकेशन मिले।

हम "स्मार्ट" रूप का दिल लॉन्च करते हैं

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

व्यावसायिक नियम द्वारा फ़ील्ड मान फ़िल्टर करें

फ़ील्ड मानों को फ़िल्टर करने का एक तरीका अंतर्निहित विशेषताओं का उपयोग करना है: DataSourceProperty और DataSourceCriteria ( प्रलेखन से उनके बारे में अधिक जानें )। उदाहरण के लिए, हम चाहते हैं कि हमारे IOrganization के प्रबंधक की संपत्ति केवल कर्मचारी संग्रह से प्रविष्टियां दिखाए, न कि IPerson प्रकार की सभी प्रविष्टियां। यह करना बहुत आसान है:

 [DataSourceProperty("Staff")] IPerson Manager { get; set; } 

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

 [DataSourceProperty("Department.Staff")] 

यदि हम फ़िल्टर को और परिष्कृत करना चाहते हैं, तो आवश्यक मापदंड के साथ एक DataSourceCriteriaAttribute जोड़ें:

 [DataSourceProperty("Staff"),DataSourceCriteria("StartsWith(FirstName, '123')")] IPerson Manager { get; set; } 

परिणामस्वरूप, हमें ऐसा अपेक्षित परिणाम मिलता है:



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

एक व्यापार नियम के आधार पर क्षेत्र मूल्यों को नियंत्रित करना

यदि स्टाफ संग्रह खाली नहीं है, तो हमारे प्रबंधक फ़ील्ड को अनिवार्य बनाएं। ऐसा करने के लिए, अंतर्निहित विशेषता RuleRequiredField का उपयोग करें और अपने TargetCriteria पैरामीटर में आवश्यक शर्त सेट करें:

 [RuleRequiredField(TargetCriteria = "Staff.Count > 0")] IPerson Manager { get; set; } 

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

इसे देखें! उदाहरण के लिए, हम यह सुनिश्चित करना चाहते हैं कि हमारे IAccount का ईमेल क्षेत्र एक अनूठा और मान्य ईमेल पता होगा। ऐसा करने के लिए, बस एक जोड़े को और अधिक तैयार विशेषताएं जोड़ें:

 [RuleRequiredField, RuleUniqueValue] [RuleRegularExpression(@"^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[az]{2,4})$")] string Email { get; set; } 

त्रुटियों को अंतर्निहित सत्यापन मॉड्यूल का उपयोग करके कल्पना की गई थी, जिसका उपयोग नए eXpressApp फ्रेमवर्क डिफ़ॉल्ट समाधान में किया जाता है:



क्या यह याद रखने योग्य है कि कोड में अधिक जटिल डेटा नियंत्रण नियम बनाने, या मौजूदा नियमों को कॉन्फ़िगर करने / एप्लिकेशन मेटाडेटा में नए नियमों की घोषणा करने का एक आसान अवसर है:



इन रूपों को नियंत्रित करने की संभावनाओं के बारे में अधिक जानने के लिए , दस्तावेज देखें।

व्यापार नियम के आधार पर, खेतों की उपस्थिति, दृश्यता और पहुंच, साथ ही अन्य नियंत्रणों में परिवर्तन

यह कार्यक्षमता बिल्ट-इन कंडिशनल अपीयरेंस मॉड्यूल द्वारा प्रदान की जाती है, जो कि विज़ुअल स्टूडियो टूलबॉक्स से केवल खींचकर और गिराकर हमारी परियोजना में जोड़ना आसान है, जबकि मॉड्यूल डिजाइनर (नीचे दिए गए चित्र में दिखाया गया है) या पूरे एक्सपीरिया एप्लिकेशन के डिजाइनर:



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

तो, चलिए शुरू करते हैं:

1. शैली में बदलाव

   
   

    [Appearance("MarkUnsafePasswordInRed", "Len(Password) < 6", FontColor = "Red")] string Password { get; set; } 

   
   यह नियम पासवर्ड फ़ील्ड को लाल रंग में हाइलाइट करेगा यदि इसमें छह से कम अक्षर हैं:
   
   
   
   एक वास्तविक आवेदन में, मुझे लगता है कि आप इस तरह के बैकलाइट के साथ बहुत कम लोगों को डराते हैं, और शायद इस तरह के नियमित नियंत्रण के साथ डेटा नियंत्रण नियम को फिर से लागू करना बेहतर है: "^ (! =। * [A-zA-Z]) (=? * * D \ _ )। {6,} $ ”।
   
   आप एक ही नाम के विशेषता मापदंडों का उपयोग करके पृष्ठभूमि का रंग और फ़ॉन्ट सेटिंग्स भी बदल सकते हैं।
   
   मैं खेतों को उजागर करने के लिए "कोशिश" करके भी विचलित होना चाहूंगा, क्योंकि अनुभव से यह अक्सर न केवल किसी वस्तु की स्थिति (सामान्य / इतनी-इतनी / बुरी) का संकेत देने के लिए उपयोगी होता है, बल्कि फॉर्म ("वर्कफ़्लो") पर चरणों के सही अनुक्रम को संकेत देने के लिए भी होता है।
   
   इसलिए, उदाहरण के लिए, हमारी आंतरिक त्रुटि ट्रैकिंग प्रणाली में (वैसे, 2006 में वापस XAF में लिखा गया है), मैंने निम्नलिखित नियम की स्थापना की है, जो हरे रंग में आवश्यक डुप्लिकेट आईडी फ़ील्ड को उजागर करता है, जिससे त्रुटि रिपोर्ट में डुप्लिकेट स्थिति सेट करने के बाद नेत्रहीन मुझे सही रास्ता दिखा रहा है। :
   

    <AppearanceRule Id="HighlightDuplicateWhenNonDraft" Criteria="Status.Name == 'Duplicate' AND !Draft" BackColor="192, 255, 192" Context="DetailView" TargetItems="OriginalIssue" Index="9" IsNewNode="True" /> 

   
   

2. उपलब्धता बदलें

   
   

    [Appearance("ChangeManagerAvailabilityAgainstStaff", "Staff.Count = 0", Enabled = false)] IPerson Manager { get; set; } 

   
   यदि स्टाफ संग्रह खाली है, तो यह नियम प्रबंधक क्षेत्र को अनुपलब्ध बना देगा:
   
   
   
   

3. दृश्यता में परिवर्तन

   
   यदि हम पिछले नियम को थोड़ा बदल देते हैं, तो हम पहुँच क्षमता के बजाय दृश्यता को नियंत्रित कर सकते हैं:
   

    [Appearance("ChangeManagerAvailabilityAgainstStaff", "Staff.Count = 0", Visibility = ViewItemVisibility.Hide)] 

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

ये सभी नियम सूची दृश्य में भी काम करेंगे, चाहे वह देखने या संपादन मोड में हो (हमारे डेमो एप्लिकेशन से चित्र देखें):



फिर, आप न केवल कोड में विशेषताओं के माध्यम से, बल्कि एप्लिकेशन मेटाडेटा के माध्यम से भी ऐसे नियम निर्धारित कर सकते हैं:

व्यावसायिक नियम के आधार पर फ़ील्ड का मान बदलें

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

 [Calculated("Concat(FirstName, ' ', LastName)")] string FullName { get; } [Calculated("Invoices[Status == 'Completed'].Sum(Amount)")] decimal SaleAmount { get; } 

विशेषताओं के उपयोग के बिना कुछ और अधिक जटिल पहले से ही प्रोग्राम किया जा सकता है।

आग लगाएं ...

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

दुर्भाग्य से, ऐसे समय थे जब यह विशेषता संदिग्ध लाभ लेकर आई। मैं उन लोगों को याद नहीं कर सकता हूं, जिनके पास 80 के बारे में नियम हैं, जो कि तत्काल फॉर्म पर फ़ील्ड्स की उपस्थिति को समायोजित करने के लिए ImmediatePostDataAttribute के साथ संयोजन करते हैं (मुझे पता नहीं है कि यह विशेषताओं के लिए बहुत प्यार है, या शुरुआती व्यावसायिक आवश्यकताओं की वजह से)। हमें थोड़ा पसीना बहाना पड़ा ताकि उत्पादकता "स्तर" पर रहे, और इस तरह के आग्रह से फॉर्म "मर" नहीं गया।

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

जारी रखने के लिए ...

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