क्या समाधान में फ़ोल्डर नामस्थान से मेल खाते हैं?

क्या समाधान में फ़ोल्डर नामस्थान से मेल खाते हैं?

मेरी टीमों में से एक परियोजनाओं में, हमारे पास एक कक्षा पुस्तकालय है जिसमें परियोजना में कई उप-फ़ोल्डर्स हैं।

प्रोजेक्ट का नाम और नामस्थान: MyCompany.Project.Section

इस प्रोजेक्ट के भीतर, नामस्थान अनुभाग से मेल खाने वाले कई फ़ोल्डर्स हैं:

  • फ़ोल्डर <�कोड> वाहन में MyCompany.Project.Section.Vehicles नेमस्पेस
  • में कक्षाएं हैं
  • फ़ोल्डर <�कोड> कपड़ों में MyCompany.Project.Section.clothing नेमस्पेस
  • में कक्षाएं हैं
  • आदि।

इस परियोजना के अंदर, एक और दुष्ट फ़ोल्डर है

  • फ़ोल्डर BusinessObjects में MyCompany.Project.Section नेमस्पेस
  • में कक्षाएं हैं

ऐसे कुछ मामले हैं जहां फ़ोल्डरों को "संगठनात्मक सुविधा" के लिए बनाया जाता है।

मेरा सवाल है: मानक क्या है? कक्षा पुस्तकालयों में फ़ोल्डरों आमतौर पर नामस्थान संरचना से मेल खाते हैं या यह एक मिश्रित बैग है?

0
ro fr bn
नोट: यदि नामस्थान फ़ोल्डर पदानुक्रम से मेल नहीं खाता है तो ReSharper शिकायत करेगा।
जोड़ा लेखक Fred, स्रोत

6 उत्तर

हां, उन्हें केवल भ्रम की ओर ले जाना चाहिए।

0
जोड़ा

मैं हाँ कहूंगा।

सबसे पहले, नामस्थानों का पालन करके वास्तविक कोड फ़ाइलों को ढूंढना आसान होगा (कहें, जब कोई आपको नग्न अपवाद कॉल स्टैक ई-मेल करता है)। यदि आप अपने फ़ोल्डरों को नामस्थानों के साथ सिंक से बाहर जाने देते हैं, तो बड़े कोडबेस में फ़ाइलों को ढूंढना थकाऊ हो जाता है।

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

बेशक, यह कहने के बिना चला जाता है कि किसी को गहन xis फ़ोल्डर / नेमस्पेस पदानुक्रम के बारे में रूढ़िवादी होना चाहिए।

0
जोड़ा

मुझे लगता है कि मानक, .NET के भीतर, संभव होने पर इसे करने का प्रयास करना है, लेकिन कठिन नियम के रूप में इसका पालन करने के लिए अनावश्यक रूप से गहरी संरचनाएं नहीं बनाना है। मेरी कोई भी परियोजना नामस्थान == संरचना नियम का 100% समय का पालन नहीं करती है, कभी-कभी इसके नियमों से बाहर निकलने के लिए केवल क्लीनर / बेहतर होता है।

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

0
जोड़ा
मैं कहूंगा "ऐसा करें जब आप वास्तव में अपने नामस्थान में कुछ होना चाहते हैं"। यह एक सचेत निर्णय होना चाहिए। यदि आपकी परियोजनाएं ठीक से अलग हैं, तो यह प्रति परियोजना एक नामस्थान होना चाहिए। यदि आपकी कक्षा किसी नामस्थान में है, तो यह उस नामस्थान या एक उपफोल्डर स्थान वाले फ़ोल्डर में होना चाहिए जो नामस्थान के रूप में कम से कम विशिष्ट है। Car.Ford.Fusion जैसी एक कक्षा (यदि कार.फोर्ड आपका एकमात्र नेमस्पेस है) कार / फोर्ड या कार / फोर्ड / सेडान जैसे गहरे फ़ोल्डर में होना चाहिए, जैसे फ़ोल्डर कम से कम नामस्थान के रूप में विशिष्ट के रूप में। बस इसे कार / असंबंधित / फोर्ड में न डालें; य
जोड़ा लेखक Triynko, स्रोत
यह स्वीकार्य उत्तर क्यों नहीं है? यह होना चाहिए।
जोड़ा लेखक Luty, स्रोत

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

कक्षाएं ढूंढना आसान हो जाएगा और अकेले ही पर्याप्त कारण होना चाहिए।

हमारे द्वारा अनुसरण किए जाने वाले नियम हैं:

  • परियोजना / असेंबली नाम रूट नामस्थान के समान है, .dll ending
  • को छोड़कर
  • उपर्युक्त नियम का अपवाद केवल एक प्रोजेक्ट है। कोर समाप्त होने पर, कोर हटा दिया गया है
  • फ़ोल्डर नामस्थान के बराबर
  • प्रति फ़ाइल एक प्रकार (वर्ग, संरचना, enum, प्रतिनिधि, आदि) सही फ़ाइल को ढूंढना आसान बनाता है
0
जोड़ा
"के लिए +1 उपर्युक्त नियम के लिए केवल अपवाद है। कोर समाप्त होने के साथ,। कोर को" अकेले बंद कर दिया गया है। मेरे पास MyProject.Core.dll असेंबली है और सभी वर्ग MyProject.Core से शुरू होते हैं। .Core प्रत्यय को अलग करना अधिक समझ में आता है।
जोड़ा लेखक Luiz Damim, स्रोत
एक और अपवाद जो मैं जोड़ सकता हूं अपवादों के लिए है। अपवाद पहले ही 'अपवाद' से भरे हुए हैं, इसलिए एक अतिरिक्त नामस्थान अनावश्यक है। यह अपवाद शब्द के साथ नेमस्पेस का एक हिस्सा होने में गन्दा हो सकता है (सिस्टम को भ्रमित करने का कारण बन सकता है। अपवाद)। हालांकि, उन्हें फ़ोल्डरों में व्यवस्थित करना काफी उपयोगी है।
जोड़ा लेखक phillipwei, स्रोत

@lassevk: मैं इन नियमों से सहमत हूं, और जोड़ने के लिए एक और है।

जब मैंने कक्षाओं को घोंसला दिया है, तो भी मैं उन्हें प्रति फ़ाइल में विभाजित करता हूं। इस कदर:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

तथा

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
0
जोड़ा

नहीं।

मैंने एकल (मुझे) और डेवलपर्स की एक टीम के साथ छोटी और बड़ी परियोजनाओं पर दोनों विधियों की कोशिश की है।

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

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

उदाहरण के लिए यह FxCop चेतावनी लें:

CA1020: कुछ प्रकार के नामस्थानों से बचें
  कारण: वैश्विक नामस्थान के अलावा एक नामस्थान में पांच से कम प्रकार शामिल हैं    https://msdn.microsoft.com/en-gb/library/ms182130.aspx

यह चेतावनी नई फाइलों को एक सामान्य प्रोजेक्ट में डंपिंग को प्रोत्साहित करती है। सामान्य फ़ोल्डर, या यहां तक ​​कि प्रोजेक्ट रूट जब तक कि आपके पास एक नया फ़ोल्डर बनाने के लिए चार समान वर्ग नहीं हैं। क्या वह कभी होगा?

फ़ाइलें ढूंढना

स्वीकार्य उत्तर कहता है "कक्षाएं ढूंढना आसान हो जाएगा और अकेले ही पर्याप्त कारण होना चाहिए।"

मुझे संदेह है कि उत्तर एक ऐसे प्रोजेक्ट में एकाधिक नेमस्पेस रखने का जिक्र कर रहा है जो फ़ोल्डर संरचना में मैप नहीं करता है, जो कि मैं सुझाव दे रहा हूं कि एक एकल नामस्थान वाला प्रोजेक्ट है।

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

नाम संघर्ष

निश्चित रूप से कई नामस्थान बनाने से परियोजना को एक ही नाम के साथ दो कक्षाएं मिल सकती हैं। लेकिन क्या यह वास्तव में एक अच्छी बात है? क्या संभव है कि इसे संभवतः अस्वीकार करना आसान हो? एक ही नाम के साथ दो वर्गों को अनुमति देना एक जटिल परिस्थिति बनाता है जहां 9 0% चीजें एक निश्चित तरीके से काम करती हैं और फिर अचानक आपको लगता है कि आपके पास एक विशेष मामला है। मान लें कि आपके पास अलग-अलग नामस्थानों में परिभाषित दो आयताकार वर्ग हैं:

  • वर्ग प्रोजेक्ट 1। इमेज.रेक्टंगल
  • कक्षा Project1.Window.Rectangle

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

var rectangle = new Project1.Window.Rectangle();

या कथन का उपयोग कर कुछ बुरा कथन के बारे में गड़बड़:

using Rectangle = Project1.Window.Rectangle;

आपकी परियोजना में एक ही नामस्थान के साथ आपको अलग-अलग आने के लिए मजबूर होना पड़ता है, और मैं अधिक वर्णनात्मक तर्क दूंगा, इस तरह के नाम:

  • वर्ग प्रोजेक्ट 1। इमेजरेक्टंगल
  • कक्षा Project1.WindowRectangle

और उपयोग हर जगह समान होता है, जब फ़ाइल दोनों प्रकारों का उपयोग करती है तो आपको किसी विशेष मामले से निपटने की आवश्यकता नहीं होती है।

using statements

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

बनाम

using Project1;

कोड लिखते समय हर समय नेमस्पेस जोड़ने की आसानी नहीं है। यह वास्तव में समय नहीं लेता है, यह करने के प्रवाह में ब्रेक है और केवल फाइलों को भरने के साथ-साथ बहुत सारे कथनों के साथ भरना - क्या? यह इसके लायक है?

Changing project folder structure

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

प्रोजेक्ट में एक ही नामस्थान के साथ आप प्रोजेक्ट फ़ोल्डर संरचना को बदल सकते हैं, हालांकि आप बिना किसी स्रोत फाइल के संशोधित किए बिना चाहते हैं।

Visual Studio automatically maps the namespace of a new file to the project folder it's created in

Unfortunate, but I find the hassle of correcting the namespace is less than the hassle of dealing with them. Also I've got into the habit of copy pasting an existing file rather than using Add->New.

Intellisense and Object Browser

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

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

0
जोड़ा
यह मैंने देखा है कि सलाह के सबसे अच्छे टुकड़ों में से एक है। नेमस्पेस केवल कक्षाओं का आयोजन नहीं, संघर्ष समाधान के लिए हैं। नामस्थानों का उपयोग केवल तभी करें जहां उन्हें उपयोग करने के लिए समझदारी हो, जैसे कि जहां आप अपनी परियोजना का उपयोग कर रहे अन्य परियोजनाओं के साथ संघर्ष नामकरण करने की अपेक्षा करते हैं, कुछ नामस्थानों को शामिल करने या बयानों का उपयोग करने के अलावा छोड़कर। यह भयानक टी में 3 या 4 या अधिक नामस्थानों वाला प्रोजेक्ट होता है जिसका उपयोग अक्सर किया जाता है, क्योंकि यह हमेशा उन कथनों का उपयोग करने की हास्यास्पद संख्या में परिणाम देता है जिन्हें आपको जोड़ने और जोड़ने और जोड़ने और ज
जोड़ा लेखक Triynko, स्रोत
नामस्थानों का सबसे बड़ा बिंदु टकराव और अस्पष्टता नामकरण से बचने के लिए है, सही? मैं उपयोग बयान बिंदु के बारे में 100% सहमत हूं। कभी-कभी जब आप एक अरब नामस्थान / उपयोग करते हैं तो नए देवताओं को लाने के लिए यह केवल शुद्ध पागलपन है। एक्सटेंशन विधियां ऐसी जगह का उदाहरण हैं जहां आईडीई आमतौर पर इसके सहायक से कम है। नेमस्पेस / फ़ोल्डर नियम को तोड़ने से बचने के लिए यह एक ही फ़ोल्डर में आपकी सभी फाइलें (या यहां तक ​​कि बहुत अधिक) डालने के लिए भी उतना ही पागल है।
जोड़ा लेखक jocull, स्रोत
मैं @ बेंटऑनकोडिंग से सहमत हूं। आपकी पोस्ट में एक और चीज यह भी बताती है कि नेमस्पेस टाइप करना आम तौर पर उन वर्गों के साथ वर्बोजिटी की आवश्यकता होती है, जिनके नाम अलग-अलग नामस्थानों में समान नाम रखते हैं, हालांकि सी # का उपयोग करके फू को बार निर्देश के साथ कर सकता है
जोड़ा लेखक Evin Ugur, स्रोत
यह ईमानदारी से सुझाए गए सबसे दुःस्वप्न समाधानों में से एक है। यदि आप छोटी हैलो वर्ल्ड प्रोजेक्ट्स पर काम करते हैं तो यह सलाह काम करती है, लेकिन कल्पना करें कि आपके पास 1000+ .cs फ़ाइलें हैं। यह इतनी सारी समस्याओं का कारण बन जाएगा जो मुझे नहीं पता कि कहां से शुरू करना है।
जोड़ा लेखक BentOnCoding, स्रोत
@WeylandYutani मुझे पता है कि मुझे देर हो चुकी है, लेकिन मुझे यह वाक्य उल्लेख करने की आवश्यकता है: आप इसे जाने के लिए परिभाषा का उपयोग करके या विजुअल स्टूडियो में खोज समाधान एक्सप्लोरर बॉक्स का उपयोग करके पा सकते हैं। कोशिश करें कि बहुत सारी विरासत और इंटरफेस ... सही फ़ाइल खोजने पर शुभकामनाएँ।
जोड़ा लेखक Emmanuel M., स्रोत
सोचने के लिए +1। मुझे नहीं लगता कि मैं अपने नामस्थानों को प्रति परियोजना में कम करने के लिए तैयार हूं लेकिन बड़े ढांचे पर काम करने के बाद मैं विवरणों की संख्या को कम करने और विस्तार विधियों की खोज में सहायता के लिए नामस्थानों की संख्या को कम करने की खोज कर रहा हूं। मुझे लगता है कि यह जवाब विचार के लिए कुछ अच्छा खाना देता है। धन्यवाद।
जोड़ा लेखक Lee Gunn, स्रोत
"लेकिन कल्पना करें कि आपके पास 1000+ .cs फाइलें हैं"। मैंने एक ही नामस्थान के साथ उस आकार की परियोजनाओं में काम किया है। यह ठीक है। आपको क्या लगता है कि आपदा क्या होगी?
जोड़ा लेखक Weyland Yutani, स्रोत
मैंने उल्लेख किया कि, मैं इसे सुंदर नहीं मानता, मुझे लगता है कि यह एक हैक है
जोड़ा लेखक Weyland Yutani, स्रोत
आपके सभी वैध बिंदुओं के बावजूद आप हार जाते हैं क्योंकि विजुअल बेवकूफ ने एक पैटर्न और डिफ़ॉल्ट चुना है। इससे भी बदतर वे एक वर्चुअल फ़ाइल संरचना का पालन करते हैं, इसलिए असली फ़ोल्डर भी नामस्थान नहीं है जो दोनों दृष्टिकोणों के लिए सिर्फ भयानक है।
जोड़ा लेखक Tommy Holman, स्रोत