EXpressApp फ्रेमवर्क (XAF) के स्मार्ट रूप। भाग 2 - मेटामोडेल यूआई अनुप्रयोग

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

व्यवसाय इकाई कोड में विशेषताएँ मेटामॉडल में सेटिंग्स

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

1. [ DomainComponent ]
2. पब्लिक इंटरफ़ेस IAccount {
3. [ RuleRequiredField, RuleUniqueValue ]
4. ] *! [[az] {2,4}) $ " ) ]
5. स्ट्रिंग ईमेल { प्राप्त करें ; सेट ; }
6. [ फील्डसाइज़ ( 25 ) ]
7. [ इमीडिएटपोस्टडाटा ]
8. [ सूरत ( "MarkUnsafePasswordInRed" , "लेन (पासवर्ड) <6" , FontColor = "Red" ) ]
9. स्ट्रिंग पासवर्ड { मिलता है ; सेट ; }
10. }
11. [ XafDefaultProperty ( " FullName " ) ]
12. [ DomainComponent, ImageName ( "BO_Person" ) ]
13. सार्वजनिक इंटरफ़ेस IPerson {
14. स्ट्रिंग LastName { प्राप्त करें ; सेट ; }
15. स्ट्रिंग FirstName { प्राप्त करें ; सेट ; }
16. [ परिकलन ( "कॉनसैट (इसनुल (फर्स्टनाम, ''), '', इसनॉल (लास्टनाम, '')" ]]
17. स्ट्रिंग FullName { मिलता है ; }
18. डेटटाइम बर्थडे { मिलता है ; सेट ; }
19. }
20. [ DomainComponent ]
21. सार्वजनिक इंटरफ़ेस I
22. [ RuleRequiredField ]
23. स्ट्रिंग नाम { मिलता है ; सेट ; }
24. [ एकत्र ]
25. IList < IPerson > कर्मचारी { प्राप्त करें ; }
26. [ RuleRequiredField ( TargetCriteria = "Staff.Count> 0" ) ]
27. [ DataSourceProperty ( "Staff" ) / *, DataSourceCriteria ("StartWWith (FirstName, '123')") * / ]
28. सूरत
29. IPerson प्रबंधक { प्राप्त करें ; सेट ; }
30. }

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

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

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

आवेदन मेटामोडेल या, इसके अलावा, प्याज ...

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



XAF शब्दों में परतों के बीच परिवर्तन या अंतर को आमतौर पर मॉडल अंतर कहा जाता है। इसलिए XML मॉड्यूल फ़ाइलों के लिए "Model.DesignedDiffs.XAFML" नाम इन अंतरों से युक्त है। मैं ध्यान देता हूं कि आप प्रत्येक परत की सामग्री को कई तरीकों से बदल सकते हैं:

1. विशेष दृश्य संपादक - मॉडल संपादक ;
2. सीधे XAFML फ़ाइलों को संपादित करना;
3. प्रोग्राम कोड के माध्यम से।

सभी परतों का सुपरपोजिशन अंतिम आवेदन मॉडल बनाएगा:



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

मैं यहां परतों के बारे में बहुत सारी बातें कर रहा हूं, लेकिन मैंने विस्तार से नहीं बताया कि हम उनके साथ क्यों आए थे, क्योंकि हमारे ढांचे के ढांचे के बाहर बहुत सारे अनुप्रयोग और प्रौद्योगिकियां हैं, जहां कोई परतें नहीं हैं, उदाहरण के लिए XAML लें। इसलिए, मैं XAF एप्लिकेशन के बहुपरत मेटामोडेल बनाने के मुख्य कारणों / आवश्यकताओं के नीचे सूचीबद्ध करूंगा:

1. कई प्लेटफार्मों के लिए लचीले ढंग से अनुप्रयोगों को कॉन्फ़िगर करने की क्षमता;
2. रनटाइम पर एप्लिकेशन कॉन्फ़िगरेशन के कारण विकास में तेजी;
3. मानक व्यवहार को बदलने वाले कस्टम मॉड्यूल का आसान विकास;
4. प्रशासक द्वारा पहले से ही तैनात आवेदन को केंद्रीय रूप से कॉन्फ़िगर करने की क्षमता;
5. अंत उपयोगकर्ताओं के लिए एप्लिकेशन की उपस्थिति और व्यवहार को व्यक्तिगत रूप से बदलने की क्षमता (गतिशील रूप से, उदाहरण के लिए, एक्सेस अधिकारों के आधार पर)।

मेटामॉडल के व्यावहारिक उदाहरण

मुझे लगता है कि पर्याप्त सिद्धांत है, और चलो व्यवहार में हमारे मेटामोडेल के साथ काम करते हैं। ऐसा करने के लिए, हमारे एप्लिकेशन का पुनर्निर्माण करें और हमारे पिछले एप्लिकेशन के प्लेटफार्म-स्वतंत्र मॉड्यूल के Model.DesignedDiffs.xafml फ़ाइल पर क्लिक करें (या सॉल्यूशन एक्सप्लोरर में संदर्भ मेनू से संबंधित कमांड को कॉल करें):



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

कल्पना करें कि हमें अचानक अपने किसी एक रूप (ICustomer_ListView) की उपस्थिति को बदलने की आवश्यकता थी। यदि हम एक कॉलम को हटाते हैं, दूसरे के लिए सॉर्टिंग सेट करते हैं, कॉलम के क्रम को बदलते हैं और अंत में हमारे आवेदन को रूसी में स्थानीयकृत करते हैं, तो यह XML संबंधित परत (Habr.Module / ModelDesignedDiffs.XAFML) में सहेजा जाएगा, जो वास्तव में है। पिछली परत से अंतर:

1. <? xml संस्करण = "1.0" एन्कोडिंग = "utf-8" ?>
2. <अनुप्रयोग का शीर्षक = "HabrDemo" लोगो = "ExpressAppLogo" >
3. <दृश्य >
4. <ListView Id = "ICustomer_ListView" >
5. <कॉलम >
6. <ColumnInfo Id = "Name" SortOrder = "अवरोही" />
7. <ColumnInfo Id = "Email" Index = "1" />
8. <ColumnInfo Id = "Manager" Index = "2" />
9. <ColumnInfo Id = "Password" हटा दिया गया = "True" />
10. </ कॉलम >
11. </ ListView >
12. </ दृश्य >
13. </ अनुप्रयोग >

* अंतरिक्ष को बचाने के लिए, मैं विशेष रूप से यहां स्थानीयकरण प्रदान नहीं करता हूं जिसके लिए एक अलग XAFML फ़ाइल बनाई जाएगी।

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



तकनीकी रूप से, इसका मतलब है कि हमारा कोड (मानक XAF मॉड्यूल से) मेटामॉडल में बदल गया और तदनुसार नियंत्रणों को कॉन्फ़िगर किया गया।

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

"रबर" ऑटो-जनरेट किए गए रूपों का बहुत विचार था, मूल रूप से, डेवलपर्स के लिए जीवन को आसान बनाने के लिए, और यह दो मुख्य समस्याओं को हल करता है:

1. विकास के स्तर पर रूपों का अधिक सुविधाजनक और त्वरित विन्यास
2. अधिक सुविधाजनक तैनाती और आवेदन समर्थन

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

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



यह उपकरण आपको मेटामोडेल के स्रोत और लक्ष्य परतों का चयन करने की अनुमति देता है और वास्तव में उन्हें एक में मिला देता है।

मेटामोडेल की आंतरिक संरचना और विस्तार के बारे में थोड़ा और

ऊपर, मैंने एक्सएफ़एमएल फ़ाइल का एक टुकड़ा दिखाया, जहाँ आपने शायद इसमें देखा था अनुप्रयोग, दृश्य, सूची दृश्य और अन्य तत्व जो मेटामोडेल के अलग-अलग तत्व हैं। अंदर, इन तत्वों को डोमेन घटकों (डीसी) तकनीक के माध्यम से पहले से ही पहले लेख में जाना जाता है (बिल्कुल सटीक होने के लिए, इसके हल्के संस्करण के माध्यम से लागू किया जाता है, जो सिल्वरलाइट को पूर्ण .NET के समान मुख्य रूप से संदर्भित करता है):

1. सार्वजनिक इंटरफ़ेस IModelListView : IModelObjectView, IModelView, IModelNode
2. {
3. IModelColumns कॉलम { प्राप्त करें ; }
4. [ DataSourceProperty ( "Application.Views" ) , DataSourceCriteria ( "(AsObjectView यह शून्य नहीं है) और (AsObjectView.ModelClass शून्य नहीं है) और ('' This.ModelClass 'शून्य नहीं है) और (AsObjectView.ModelClass.Name =) यह.मॉडलक्लास.नाम ') " ) ]
5. IModelDetailView विस्तार से देखें { प्राप्त करें ; सेट ; }
6. [ DataSourceProperty ( "ModelClass.ListEditorsType" ) ]
7. टाइप संपादक टाइप { get ; सेट ; }
8. IModelSorting सॉर्टिंग { प्राप्त करें ; }
9. बूल UseServerMode { get ; सेट ; }
10. ... और अन्य गुण जो वस्तुओं की सूची के साथ रूपों को चिह्नित करते हैं ( सूची दृश्य )
11. }

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

मॉडल तत्वों का एक मानक सेट सिस्टम मॉड्यूल से प्राप्त होता है जो डिफ़ॉल्ट रूप से एक नई XAF परियोजना से जुड़ता है। यह ध्यान देने योग्य है कि परतों में एक अलग "स्कीमा" (एक्सएमएल के लिए) हो सकता है, अर्थात। एप्लिकेशन मॉडल के तत्वों का एक सुलभ सेट या योजना, जो सीधे परत के निर्माण के लिए उपयोग किए जाने वाले मॉड्यूल पर निर्भर करता है। इसलिए, उदाहरण के लिए, हमारे पास IModelListView - एक एप्लिकेशन मॉडल तत्व है जो प्लेटफ़ॉर्म-स्वतंत्र मॉड्यूल में सूची दृश्य संरचना को परिभाषित करेगा। प्लेटफ़ॉर्म-विशिष्ट तत्व, IModelListViewWeb और IModelListViewWin भी हैं, गुणों की अपनी अनूठी सेट के साथ जो वस्तुओं की सूची के साथ रूपों को चिह्नित करते हैं। व्यवहार में, इसका मतलब है कि वेब के लिए हमारे मॉड्यूल के लिए मॉडल संपादक (Habr.Module.Web / ModelDesignedDiffs.XAFML) खोला गया है, हम नए तत्वों और विकल्पों को देखेंगे, उदाहरण के लिए SaveListViewStateInChies ।

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

1. सार्वजनिक इंटरफ़ेस IModelListViewEx {
2. स्ट्रिंग MyCoolOption { मिलता है ; सेट ; }
3. }
4. सार्वजनिक ओवरराइड शून्य एक्सटेंडमोडेलइंटरफेस ( मॉडलइंटरफेसटेक्स्टेंडर एक्सटेंडर ) {
5. आधार । ExtendModelInterfaces ( एक्सटेंडर ) ;
6. extenders। < IModelListView, IModelListViewEx > ( ) जोड़ें ;
7. }

यदि आप तत्व कोड के मालिक हैं, तो बस इस विकल्प को इंटरफेस में जोड़ें या स्पष्ट रूप से अपने इंटरफ़ेस एक्सटेंशन को "मिक्स" करें:

1. सार्वजनिक इंटरफ़ेस IModelLayoutViewItem : IModelLayoutItem, IModelViewLayoutElement, IModelLayoutElementWithCaptionOptions, IModelNode, ISupportontontrolAlignment, IModelToolTip, IModelToolTipOptions

बेशक, डेवलपर मॉडल के निर्माण के अन्य पहलुओं को लचीले ढंग से नियंत्रित कर सकता है, जैसे कि शून्य परत उत्पन्न करना (वास्तव में, आप मानक और कस्टम मॉडल तत्वों के अपने स्वयं के जनरेटर बना सकते हैं), मॉडल संपादक में व्यवहार और प्रदर्शन को अनुकूलित करना, आदि।

निष्कर्ष

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

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

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