.NET नेमस्पेस

Question

मेरी पृष्ठभूमि मुख्य रूप से जावा डेवलपर के रूप में है, लेकिन हाल ही में मैं .NET में कुछ काम कर रहा हूं। इसलिए मैं .NET के साथ काम करने के लिए बेहतर होने के लिए घर पर कुछ सरल परियोजनाएं करने की कोशिश कर रहा हूं। मैं अपने अधिकांश जावा अनुभव को .NET (विशेष रूप से सी #) के साथ काम करने में स्थानांतरित करने में सक्षम हूं, लेकिन एकमात्र चीज जो वास्तव में मुझे परेशान करती है वह नामस्थान है।

मुझे पता है कि नामस्थान जावा पैकेज के समान हैं, लेकिन जैसा कि मैं मुख्य अंतर बता सकता हूं कि जावा पैकेज के साथ वे पृथक्करण दिखाने के लिए वास्तविक फ़ाइल फ़ोल्डरों का उपयोग करते हैं, जबकि .NET में यह नहीं है और सभी फाइलें मौजूद हैं एक ही फ़ोल्डर में और प्रत्येक वर्ग में नामस्थान बस घोषित किया जाता है।

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

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

संपादित करें: जैसा कि ब्लेयर ने इंगित किया है कि यह वही प्रश्न है जो here से पूछा गया है।

Answer 1

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

मैं आपको आवश्यकतानुसार अधिक परियोजनाओं में कोड को तोड़ने का थोड़ा सा झुकाव करूंगा, क्योंकि यह संकलन धीमा कर सकता है और आपको कई असेंबली प्रबंधित करने के लिए ओवरहेड जोड़ना पड़ सकता है।

संपादित करें: ध्यान दें कि इस सवाल का लगभग should the folders in a solution match the namespace?

Answer 2

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

मैं आम तौर पर अपने प्रोजेक्ट में प्रत्येक नाम स्थान के लिए एक फ़ोल्डर जोड़ने के लिए, और घोंसला उन्हें एक ही पदानुक्रम के अनुसार (उदाहरण के लिए MyApp.View.Dialogs)

Answer 3

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

DefaultNamespace.FolderName.ClassName

बेशक

, आप बदल सकते हैं प्रोजेक्ट का डिफ़ॉल्ट नेमस्पेस, और अपनी कक्षाओं को आपकी इच्छानुसार किसी भी तरीके से नामित किया जाए।

जहां तक ​​परियोजनाओं में सामान तोड़ने के लिए/कैसे, यह अनुभव और/या वरीयता का मामला है। हालांकि, आपको अपनी परियोजना को व्यवस्थित रखने के लिए, समाधान के भीतर परियोजनाओं में पूरी तरह से सामान तोड़ना चाहिए। यदि बहुत से असेंबली प्रबंधित करना बोझिल हो जाता है (ब्लेयर के सुझाव के रूप में), तो आप हमेशा एक ही असेंबली में 0 असेंबली ILMerge कर सकते हैं।आईएलएमर्ज के बारे में क्या बढ़िया बात यह है कि भले ही आप केवल एक असेंबली के साथ समाप्त हो जाएं, फिर भी आपके सभी वर्ग अपने मूल रूप से योग्य नाम रखेंगे।

यह भी याद रखना महत्वपूर्ण है कि एक वीएस समाधान कोड पर कोई असर नहीं है - यानी। वे नहीं बनते हैं। वीएस समाधान परियोजनाओं को समूहबद्ध करने का एक तरीका नहीं है; यह ऐसी परियोजनाएं हैं जिन्हें डीएलएल में बनाया और बदल दिया गया है।

अंत में, वीएस चलो आप समाधान में कहीं भी "आभासी" फ़ोल्डर जोड़ते हैं। ये फ़ोल्डर्स फाइल सिस्टम में किसी फ़ोल्डर में मैप नहीं करते हैं, और समाधान के भीतर आपकी परियोजनाओं और अन्य कलाकृतियों को व्यवस्थित करने में आपकी सहायता के लिए केवल एक और माध्यम के रूप में उपयोग किया जाता है।

Answer 4

हाँ, .NET नेमस्पेस में फ़ाइल सिस्टम या किसी अन्य चीज़ पर निर्भर नहीं है। यह मेरी राय में एक बड़ा फायदा है। उदाहरण के लिए आप अपने कोड को विभिन्न असेंबली में विभाजित कर सकते हैं जो लचीला वितरण की अनुमति देता है।

विजुअल स्टूडियो में काम करते समय, आईडीई प्रोजेक्ट पेड़ में नया फ़ोल्डर जोड़ते समय नया नामस्थान पेश करता है।

Namespace Naming Guidelines

नामकरण नामस्थान के लिए सामान्य नियम कंपनी प्रौद्योगिकी नाम और उसके बाद नाम का उपयोग करें और सुविधा और डिजाइन के रूप में वैकल्पिक रूप से करने के लिए है:

यहाँ MSDN से एक उपयोगी लिंक है इस प्रकार है।
CompanyName.TechnologyName [.फ़ीचर] [। डिजाइन]

बेशक आप जिस तरह से आप अधिक उपयुक्त लगता है में नामस्थान उपयोग कर सकते हैं। हालांकि अगर आप अपना कोड साझा करने जा रहे हैं, तो मैं स्वीकार किए गए मानकों के साथ जाने की सिफारिश करता हूं।

संपादित:

मैं अत्यधिक किसी भी .net डेवलपर के लिए सुझाव देते हैं Framework design guidelines की एक प्रति इस किताब को आप को समझने के लिए कैसे और क्यों नेट डिज़ाइन किया गया है में मदद मिलेगी पाने के लिए।

Answer 5

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

आपके पास एकाधिक पुस्तकालयों, बदसूरत लेकिन सच में संदर्भित एक ही नामस्थान हो सकता है।

Answer 6

दरअसल, नेट वातावरण आपको आईडीई/फाइल सिस्टम जैसे दीवार के खिलाफ स्पेगेटी जैसे कोड को फेंकने की अनुमति देता है।

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

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

Answer 7

मैंने हमेशा स्रोत फ़ाइल संगठन माना है और कक्षाओं और वस्तुओं को पहचानकर्ताओं को दो अलग-अलग समस्याओं के लिए असाइन किया है। मैं समूह में संबंधित वर्गों को रखना चाहता हूं, लेकिन हर समूह को नामस्थान नहीं होना चाहिए। नाम विवादों की समस्या को हल करने के लिए नामस्थान (अधिक या कम) हैं- सी जैसी फ्लैट-नेमस्पेस भाषाओं में, आप mycompany_getcurrentdate या MYCGetCurrentDate जैसे पहचानकर्ताओं के बिना दो फीट नहीं चल सकते हैं, क्योंकि किसी अन्य फ़ंक्शन के साथ किसी अन्य फ़ंक्शन के साथ संघर्ष का जोखिम तीसरी पार्टी (या सिस्टम) लाइब्रेरी बहुत छोटी है। यदि आपने प्रत्येक लॉजिकल अलगाव के लिए कोई पैकेज या नेमस्पेस बनाया है, तो आपको java.lang.primitivewrapper.numeric.Integer जैसे क्लास नाम मिलेगा (जावा उदाहरण), जो काफी अधिक है।

Answer 8

नेमस्पेस एक तार्किक समूह है, जबकि परियोजनाएं एक भौतिक समूह हैं।

यह महत्वपूर्ण क्यों है? .NET 2.0, 3.0, और 3.5 के बारे में सोचें। .NET 3.0 मूल रूप से कुछ अतिरिक्त असेंबली के साथ .NET 2.0 है, और 3.5 कुछ और असेंबली जोड़ता है। तो उदाहरण के लिए, .NET 3.5 DataPager नियंत्रण जोड़ता है, जो एक वेब नियंत्रण है और इसे System.Web.UI.WebControls में समूहीकृत किया जाना चाहिए। यदि नामस्थान और भौतिक स्थान समान थे, तो ऐसा नहीं हो सकता क्योंकि यह एक अलग असेंबली में है।

इसलिए स्वतंत्र लॉजिकल इकाइयों के रूप में नामस्थान होने का मतलब है कि आप कई अलग-अलग असेंबली के सदस्य हो सकते हैं जो सभी तर्कसंगत रूप से समूहबद्ध होते हैं क्योंकि उनका उपयोग एक-दूसरे के साथ संयोजन के रूप में किया जाता है।

(इसके अलावा, वहाँ बहुत समान अपने शारीरिक और तार्किक लेआउट होने के साथ कुछ भी गलत नहीं है।)

Answer 9

अंतर यह है कि .net नामस्थान जावा संकुल के साथ क्या करना ज्यादा कुछ नहीं है।

.नेट नेमस्पेस पूरी तरह से घोषणात्मक दायरे के प्रबंधन के लिए हैं, और फाइलों, परियोजनाओं या उनके स्थानों से कोई लेना देना नहीं है।

पर एक विशेष नामस्थान में घोषित यह बहुत आसान सब कुछ सुलभ है जब आप उस नामस्थान में 'उपयोग' शामिल करते हैं।

बहुत आसान है।

नाम की पसंद और चाहे या नहीं/कितने '।' आपके द्वारा उपयोग किए जाने वाले सेपरेटर्स पूरी तरह से आपके ऊपर हैं।

वीएस डिफ़ॉल्ट रूप से कोशिश करने और सहायक होने के लिए अपने नामस्थानों में फ़ोल्डर्नम्स जोड़ने के लिए डिफ़ॉल्ट है। , http://www.blackwasp.co.uk/Namespaces.aspx

यह भी एक उदाहरण अंत की ओर नामकरण परिपाटी है, हालांकि आपके नाम सम्मेलन अपने कॉल है:

इस लेख काफी अच्छी तरह से नामस्थान बताते हैं! ;)

ने कहा कि, मैंने जिन स्थानों पर काम किया है और जिन लोगों ने मैंने कंपनी के नाम से शुरुआत की है, जो समझदार है, क्योंकि यह उस कंपनी के लिए टाइपनाम बनाता है, (अन्य, पुस्तकालयों, विक्रेताओं, ओपनसोर्स से अलग प्रोजेक्ट इत्यादि)