ऑब्जेक्ट ओरिएंटेड जिन इंस्टॉलर विकास

पहले भाग का लिंक
दूसरे भाग का लिंक
तीसरे भाग का लिंक

डेटा प्रविष्टि

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

हम एक कमांड के रूप में इनपुट फॉर्म लागू करते हैं:

public class UserInputCommand: Command { public List<UserInputControl> InputControls { get; set; } public string FormCaption { get; set; } public override void Do(ExecutionContext context) { foreach (UserInputControl input in InputControls) { Control control = input.Create(); //       context.InputForm.Controls.Add(control); } } } 

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

 public abstract class UserInputControl { public string ResultName { get; set; } public int Height { get; set; } public abstract Control Create(); } 

यह एक अमूर्त वर्ग है जिसमें से हम सभी विशिष्ट उपयोगकर्ता नियंत्रणों को वारिस करेंगे, जैसे कि UserInputTextBox - एक साधारण संपर्क इनपुट फ़ील्ड:

 public class UserInputTextBox : UserInputControl { public string Caption { get; set; } public string InitialValue { get; set; } public override Control Create() { TextBox textbox = new TextBox(); return control; } } 

यह सिर्फ सरलीकृत कोड है। वास्तव में, टेक्स्ट इनपुट फ़ील्ड के अलावा, एक लेबल भी होगा जो कैप्शन हेडर को प्रदर्शित करता है, और इन दो नियंत्रणों को पैनल में रखा जाएगा, जो वास्तव में क्रिएट विधि के परिणाम के रूप में वापस आ जाएंगे। इस उदाहरण के आधार पर, UserInputControl से विरासत में हम अन्य सभी उपयोगकर्ता नियंत्रण बनाएंगे।
साथ ही, इनपुट फॉर्म को उपयोगकर्ता इनपुट के अंत की प्रतीक्षा करनी चाहिए, जिसे मैंने अगले बटन पर क्लिक की निरंतरता के साथ एक अलग स्ट्रीम में मुख्य इंस्टॉलर नियंत्रण प्रवाह को लॉन्च करके कार्यान्वित किया।
क्रमबद्धता
मैंने XML क्रमांकन प्रारूप चुना क्योंकि यह अच्छी तरह से नेट मंच द्वारा समर्थित है। मैं System.Xml.Serialization.XmlSerializer वर्ग का उपयोग करूँगा, क्योंकि इसके उपयोग में आसानी के कारण, इसमें किसी वस्तु को क्रमबद्ध करने के लिए कोड की केवल तीन पंक्तियों को लिखने की आवश्यकता होती है, जबकि अतिरिक्त लचीलापन (यदि आवश्यक हो) System.Xml.Serialization नामस्थान के गुणों का उपयोग करके प्राप्त किया जाता है ।
यहाँ यह कोड है:

 //  XmlSerializer ser = new XmlSerializer(typeof(T)); FileStream stream = new FileStream(filePath, FileMode.OpenOrCreate, FileAccess.Write); ser.Serialize(stream, obj); // XmlSerializer ser = new XmlSerializer(typeof(T)); stream = new FileStream(filePath, FileMode.Open, FileAccess.Read); result = (T)ser.Deserialize(stream); 

जैसा कि हम देखते हैं, इसके लिए निम्नलिखित इनपुट तर्क हैं: फ़ाइल का पथ जहां अनुक्रमित ऑब्जेक्ट लिखा जाएगा; वस्तु ही; और क्रमबद्ध वस्तु का प्रकार। यह कोड अन्य वर्गों से विरासत में नहीं मिलने के लिए बहुत अच्छा है। लेकिन अगर हम क्रमबद्ध करने जा रहे हैं, उदाहरण के लिए, CreateFile वर्ग, जिसका उत्तराधिकार पदानुक्रम CreateFile <- TransactionalCommand <- कमांड है, तो T = कमांड पर, serializer हमें XmlInclude विशेषता का उपयोग करने की आवश्यकता के बारे में बताएगा, जो धारावाहिक निर्माता को सभी संभव नेस्टेड और माता-पिता वर्ग का उपयोग करने के लिए बताता है। क्रमबद्ध वस्तु। और यह इतनी समस्याग्रस्त नहीं होगी अगर इन विशेषताओं को बेस क्लास कमांड पर लागू करने की आवश्यकता नहीं है, इसके लिए निर्दिष्ट एक विशेषता XmlInclude अपने सभी संभावित वंशजों के लिए। और चूंकि मुझे लगता है कि उपयोगकर्ता कमांड वर्ग के स्रोत कोड तक पहुंच के बिना प्लग-इन के रूप में आदेशों के संग्रह में वृद्धि करेंगे, इसका मतलब यह है कि धारावाहिक उपयोगकर्ता द्वारा जोड़े गए इन सभी वर्गों को क्रमबद्ध नहीं कर पाएंगे। सौभाग्य से, वहाँ एक रास्ता है। सभी शामिल प्रकारों को न केवल विशेषताओं के साथ सेट किया जा सकता है, बल्कि XmlSerializer निर्माणकर्ता के प्रत्यक्ष तर्कों के साथ, जिसमें दूसरा तर्क प्रकार [] शामिल प्रकारों का एक सरणी हो सकता है।

 Type[] types; XmlSerializer ser = new XmlSerializer(typeof(T), types); 

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

 public class GinMetaData { public List<ExternalCommand> Commands { get; private set; } public Type[] IncludedTypes { get; private set; } public static GinMetaData GetInstance(); public void Plugin(string folderPath) public ExternalCommand GetCommandByName(string name) } 

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

 private void LoadCommandsFrom(Assembly assembly) { foreach (Type type in assembly.GetTypes()) { if (ExternalCommand.ContainsCommand(type)) { ExternalCommand cmd = new ExternalCommand(type); Commands.Add(cmd); _includedTypes.Add(cmd.CommandType); } } } 

यह केवल इस कोड में उपयोग किए गए एक्सटर्माकमैंड वर्ग पर विचार करने के लिए बना हुआ है। यहाँ इसका इंटरफ़ेस है:

 public class ExternalCommand { public ExternalCommand(Type type) public Type CommandType { get; private set; } public Command Instance { get; private set; } public PropertyInfo[] Properties { get; private set; } public ConstructorInfo Constructor { get; private set; } public CommandMetadata Metadata { get; private set; } public static bool ContainsCommand(Type type) public object GetProperty(string propertyName) public void SetProperty(string propertyName, object value) public ExternalCommand Clone() } 

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

 public class CommandMetadata { public string Name { get; set; } public string Desription { get; set; } public string Group { get; set; } } 

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

 [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)] public class GinNameAttribute : Attribute { public string Name { get; set; } public string Description { get; set; } public string Group { get; set; } } 

इसे कमांड क्लास पर लागू किया जाता है, उदाहरण के लिए इस तरह:

 [GinName( Name = "-", Description = "  if-then-else", Group = " ")] public class ExecuteIf : TransactionalCommand, IContainerCommand { // …… } 

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