.NET एप्लिकेशन के बीच कोड साझा करने का सबसे प्रभावी तरीका क्या है?


15

हमारे काम में, हमारे पास कई अलग-अलग .net अनुप्रयोग हैं जो बहुत अधिक आधार कार्यक्षमता साझा करते हैं। हमने इन एप्लिकेशन को एक साफ n-tier आर्किटेक्चर का उपयोग करके बनाया है, लेकिन हमने उस क्षण को मारा है जहां हमें एहसास होता है कि हमने एक ही कार्य को कई अलग-अलग समयों में फिर से लागू किया है। जाहिर है कि यह DRY का उल्लंघन करता है, और हम इसे ठीक करना चाहेंगे। हम पहले से ही आम गोंद कोड (IoC, लॉगिंग, सेटिंग्स को वायरिंग) के लिए कुछ सफलता के लिए Nuget का उपयोग कर रहे हैं, लेकिन हम अपने सभी अनुप्रयोगों के बीच हमारे डेटा और व्यावसायिक परतों को भी साझा करना चाहते हैं। विचार यह है कि यूआई केवल उस व्यवसाय परत के हिस्सों से निपटेगा जो वास्तव में इसकी आवश्यकता है।

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

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

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

यहां वह स्टैक है जिसका हम उपयोग कर रहे हैं: C #, TFS कंटीन्यूअस इंटीग्रेशन के साथ, Nuget। हमारे आवेदन ASP.NET अनुप्रयोगों के सभी विभिन्न प्रकार हैं। हम अलग-अलग एससीएम को देखने के लिए तैयार हैं यदि यह चीजों को आसान बना देगा।

मैं अपनी अलग स्रोत कोड शाखाओं के साथ Nuget समझ रखने के तरीकों की तलाश कर रहा हूं। हम गलती से विकास कोड को उत्पादन में धकेलना नहीं चाहते क्योंकि हम गलत Nuget पैकेज का संदर्भ देते हैं।


इसके अलावा, अगर यह इस तरह की चर्चा के लिए एक अच्छा मंच नहीं है, तो क्या कोई बेहतर सुझाव दे सकता है?
जोश

जवाबों:


9

हम नींव (फाउंडेशन-ए) में बदलाव करते हैं और उन्हें एक अस्थिर पैकेज के रूप में नगेट फीड पर धकेल देते हैं।

यहीं से आपकी समस्या शुरू होती है ... ऐसा मत करो।

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

प्रोजेक्ट बी को अपने फाउंडेशन संवर्द्धन का निर्माण करना चाहिए जैसा कि सामान्य तौर पर होता है, लेकिन (अच्छे स्रोत प्रबंधन फैशन में) एक स्थिर फाउंडेशन (v1.2) को धक्का देने से पहले ट्रंक परिवर्तन (v1.1) में विलय करना चाहिए।

अन्य परियोजनाएं जो फाउंडेशन संवर्द्धन का उपयोग कर सकती हैं, उपयुक्त होने पर अपने नगेट संदर्भ को अपग्रेड कर सकती हैं, या यदि आवश्यक हो तो पुराने संस्करणों के साथ छड़ी कर सकती हैं।

मैं @Giedrius से सहमत हूं ; यह मुझे इस अर्थ में एक स्रोत नियंत्रण / ब्रांचिंग मुद्दे से अधिक लगता है कि अगर फाउंडेशन की ब्रांचिंग / विलय को ठीक से संभाला जाता है, तो पैकेज प्रबंधन मुद्दे मूट हो जाते हैं।


हाँ, यह समझ में आता है। समस्या व्यावहारिक अनुप्रयोग में है। जब आप v1.1 के लिए फाउंडेशन के लिए अपडेट करते हैं, तो आप प्रोजेक्ट बी में उन परिवर्तनों का उपयोग करना चाहते हैं जैसे आप विकसित कर रहे हैं। यदि आप जिस कोड को साझा कर रहे हैं, वह nuget के माध्यम से है, तो आपके विकल्प हैं: 1) नया nuget पैकेज प्रकाशित करें, या 2) मैन्युअल रूप से dll के आसपास कॉपी करें। इनमें से किसी को भी अच्छे विकल्प नहीं लगते हैं।
जोश

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

@ जोश, फाउंडेशन के लिए अपडेट पूर्ण और परीक्षण योग्य होना चाहिए कि प्रोजेक्ट बी उनका उपयोग कैसे करने जा रहा है (क्योंकि वे एक साझा पुस्तकालय में जा रहे हैं), इसलिए 'नया नगेट पैकेज प्रकाशित करना' प्राकृतिक तरीका है। आयात करें और तब तक का उपयोग न करें जब तक कि प्रोजेक्ट बी में फाउंडेशन v.Next का उपयोग नगेट में एक स्थिर पैकेज में न हो। यह थोड़ा अनुशासन लेता है, लेकिन यह इसे करने की गंदगी से बहुत बेहतर है।
एरिक किंग

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

2
जैसा कि हम कुछ महीनों से कर रहे हैं, यह मूल रूप से वही है जो हमने तय किया था। मुझे लगता है कि मैं एक औपचारिक प्रक्रिया के बारे में बहुत चिंतित था। एक बार जब हमने वास्तव में इस पर काम करना शुरू कर दिया, तो चीजें वास्तव में सुचारू रूप से समाप्त हो गईं। आपके सहयोग के लिए धन्यवाद।
जोश

4

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

यह भी याद रखें कि सभी डुप्लिकेट कोड वास्तव में डुप्लिकेट नहीं हैं; इसमें से कुछ गोंद कोड या कोड है जो अन्यथा वास्तुकला को बनाए रखने के लिए आवश्यक है, इसलिए बहुत अधिक DRY होने पर भी ध्यान न दें।


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

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

4

कोड का पुन: उपयोग

कोड पुन: उपयोग के लिए कई दृष्टिकोण हैं जो वर्षों से अनुकूल पाए गए हैं। प्रत्येक दृष्टिकोण में यह जगह है, और अधिक महत्वपूर्ण रूप से इसके मुद्दे हैं , लेकिन .NET में कोड का पुन: उपयोग करने के लिए व्यवहार्य तरीके हैं:

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

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

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

NuGET का प्रबंधन

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


1

मुझे लगता है कि समस्या नगेट / सोर्स कंट्रोल / ब्रांचिंग में नहीं है, लेकिन ग्लूइंग कोड में क्या है।

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

http://ayende.com/blog/3986/let-us-burn-all-those-pesky-util- असामान्य- पुस्तकालय

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


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

0

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

या इससे भी बेहतर: इसे अपने संगठन के भीतर "ओपन-सोर्स" बनाएं। इसलिए कोई भी कोड बदल सकता है, लेकिन कुछ चुनिंदा लोगों के पास ही पूर्ण अधिकार होंगे। और वे लोग गुणवत्ता और सही सुविधाओं को सुनिश्चित करने के लिए जिम्मेदार होंगे।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.