🧑🏿‍🤝‍🧑🏽 🎂 👉🏼 ऑब्जेक्ट ओरिएंटेड जिन इंस्टॉलर विकास 🧙 👦🏼 🗼

परिचय

निम्नलिखित लेखों की श्रृंखला में कुछ मुख्य लक्ष्य हैं:

उपयोगी सॉफ़्टवेयर बनाएं - प्रोग्राम और अपडेट के लिए इंस्टॉलर।
सॉफ्टवेयर विकास के लिए एक वस्तु-उन्मुख दृष्टिकोण के लाभ दिखाएं और सिखाएं कि आसानी से एक्स्टेंसिबल सॉफ़्टवेयर आर्किटेक्चर कैसे बनाएं।

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

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

इसलिए, पहले सन्निकटन में प्रत्येक पैकेज में होना चाहिए:

निष्पादित कमांड के अनुक्रम का विवरण।
डेटा फ़ाइलों का एक मनमाना सेट।

मैं एक XML फ़ाइल में कमांड के अनुक्रम के विवरण को सहेजने का इरादा रखता हूं कि .NET प्लेटफ़ॉर्म में XML फ़ाइलों में ऑब्जेक्ट्स को क्रमांकित / डीसर्लाइज़ करने के लिए सुविधाजनक और सरल कक्षाएं शामिल हैं, जो हमें संचालन में देरी के साथ आवेदन के मुख्य तर्क पर ध्यान केंद्रित करने का अवसर देगा। पंक्तियों में।
पैकेज स्वयं एक TAR आर्काइव के प्रारूप में होगा, जो संभवतः GZIP संपीड़न के अधीन है, हालांकि, मैं सॉफ्टवेयर को इस तरह से डिजाइन करने का प्रयास करूंगा कि जब पैकेज के भंडारण विधि (इसकी संरचना और संपीड़न विधि) को बदलने का निर्णय लिया जाए, तो हमें मौजूदा कोड में न्यूनतम हस्तक्षेप की आवश्यकता होगी।
आइए भविष्य के सॉफ़्टवेयर के लिए कमांड के सेट का अनुमान लगाएं।

फ़ाइल संचालन
एसक्यूएल संचालन
IIS सर्वर प्रबंधन
शायद कुछ और ...

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

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

void CreatePackage() { //     PackageBuilder builder = new PackageBuilder(); builder.AddCommand(new CreateFolderCommand() { FolderPath = @"%APPROOT%\files" }); builder.AddCommand(new CreateFileCommand() { SourcePath = @"d:\package\config.xml", //      DestPath = @"%APPROOT%\files\config.xml" //     }); Package package = builder.GetResult(); package.SaveAs(@"d:\package\output\package.pkg"); } void ExecutePackage () { //    Package package = new Package(@"d:\package\output\package.pkg"); package.Execute(); }

बेशक, कक्षाओं की संरचना में अभी भी कई कायापलटों से गुजरने का समय होगा, लेकिन आपको कहीं शुरू करना होगा।

बेसिक कमांड सिस्टम

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

 public abstract class Command { public abstract void Do(); } public class DeleteFile: Command { public string FilePath { get; set; } public override void Do() { File.Delete(FilePath); } }

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

 public class ExecuteIf : Command { public string ArgumentName { get; set; } public Command Then { get; set; } public Command Else { get; set; } public void Do(); }

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

तो अब हमारी कक्षाएं अब इस तरह दिखती हैं:

 public abstract class Command { public abstract void Do(ExecutionContext context); } public class DeleteFile: Command { public string FilePath { get; set; } public override void Do(ExecutionContext context) { File.Delete(FilePath); } } public class ExecuteIf : Command { public string ArgumentName { get; set; } public Command Then { get; set; } public Command Else { get; set; } public void Do(ExecutionContext context); }

आदेशों के मूल सेट के वर्णन से ध्यान हटाएं, और क्लास एक्ज़ीक्यूशन कोटेक्स्ट डिज़ाइन करें।

निष्पादन का संदर्भ

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

 public class ExecutionContext { private Dictionary<string, object> _results = new Dictionary<string, object>(); public void SaveResult(string key, object value) { _results[key] = value; } public object GetResult(string key) { return _results[key]; } }

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

 public class DeleteFile: Command { public string FilePath { get; set; } private ExecutionContext _context; public DeleteFile(ExecutionContext context) { _context = context; } public DeleteFile() { } public override void Do() { } }

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

 private ExecutionContext _context; public DeleteFile(ExecutionContext context) { _context = context; } public DeleteFile () { }

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

 public class DeleteFile: Command { public string FilePath { get; set; } public override void Do(ExecutionContext context) { } }

अर्थात् इसमें कुछ भी अतिश्योक्ति नहीं है, केवल सार है। इसका मतलब यह है कि यह प्रोग्रामर के लिए आसान हो जाएगा जो इसके सार को समझने के लिए एप्लिकेशन का समर्थन और विकास करेगा।
अब हम ExecuteIf कमांड के कार्यान्वयन को लिख सकते हैं:

 public class ExecuteIf : Command { public string ArgumentName { get; set; } public Command Then { get; set; } public Command Else { get; set; } public override void Do(ExecutionContext context) { if ((bool)context.GetResult(ArgumentName)) { Then.Do(context); } else if (Else != null) { Else.Do(context); } } }

बेसिक कमांड सिस्टम।

इंस्टॉलर कमांड फ्रेमवर्क बनाने के लिए वापस आते हैं। हमने पहले से ही आधार सार वर्ग कमांड, साथ ही सशर्त कमांड ExecuteIf का वर्णन किया है। ExecuteIf कमांड के तो एंड एल्स के पैरामीटर्स केवल एक कमांड नहीं, बल्कि लगातार कमांड्स का एक पूरा ब्लॉक हो सकते हैं। और इसका मतलब है कि आपको कमांड को डिजाइन करने की आवश्यकता है - ऑपरेटर कोष्ठक का एक एनालॉग। इस कमांड को कमांडस्सेंस कहिए। इसका इंटरफ़ेस और कार्यान्वयन सरल है:

 public class CommandSequence : Command { public List Commands; public override void Do(ExecutionContext context) { foreach (Command command in Commands) { command.Do(context); } } }

इसका एकमात्र पैरामीटर आदेशों की एक सूची है, और डू () विधि बस उन्हें बदले में निष्पादित करती है।

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

 public class CompareStringsCommand: Command { public string FirstOperandName { get; set; } public string SecondOperandName { get; set; } public string ResultName { get; set; } public void Do(ExecutionContext context) { string operand1 = (string)(context.GetResult(FirstOperandName)); string operand2 = (string)(context.GetResult(SecondOperandName)); bool result = Compare(operand1, operand2); context.SaveResult(ResultName, result); } }

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

 public abstract class CompareStringsCommand: Command { public string FirstOperandName { get; set; } public string SecondOperandName { get; set; } public string ResultName { get; set; } protected abstract bool Compare(string operand1, string operand2); public override void Do(ExecutionContext context) { //    ,       } } public class StringStartsWith : CompareStringsCommand { protected override bool Compare(string operand1, string operand2) { return operand1.StartsWith(operand2); } }

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

 public class SaveConstantCommand: Command { public string ResultName { get; set; } public object Value { get; set; } public override void Do(ExecutionContext context) { context.SaveResult(ResultName, Value); } }

अगले अध्याय में, मैं लेनदेन तंत्र के कार्यान्वयन पर चर्चा करूंगा।

दूसरे भाग का लिंक

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

परिचय

बेसिक कमांड सिस्टम

निष्पादन का संदर्भ

बेसिक कमांड सिस्टम।

More articles: