नाम "कोर" असेंबली

Question

मुझे पता है कि यह कुछ हद तक व्यक्तिपरक है, लेकिन मुझे आश्चर्य है कि असेंबली नामकरण के लिए आम तौर पर स्वीकार्य मानक है जिसमें कुछ "मूल" कार्य होते हैं।

मान लीजिए कि आप

• तरह विधानसभाओं के साथ एक बड़ा परियोजनाओं मिला, Company.Product.WebControls.dll
• Company.Product.Net.dll
• Company.Product.UserPages.dll
चलो

और आपके पास ग्लोबल एरर हैंडलर, वैश्विक लॉगिंग कार्यक्षमता इत्यादि जैसे "कोर" वर्गों का एक समूह है

इस तरह की एक असेंबली आम तौर पर कैसे नामित की जाएगी?

• Company.Product.dll
• Company.Product.Core.dll
• Company.Product.Global.dll
• Company.Product.Administration.dll: ये कुछ चीजें हैं मैं मन में था कर रहे हैं

अब, जबकि "केवल एक को चुनें और आगे बढ़ें" आर्मगेडन का कारण नहीं होगा, मैं अभी भी जानना चाहता हूं कि उन असेंबली का नाम देने के लिए "स्वीकार्य" तरीका है या नहीं।

Answer 1

नेट के साथ यह बदलने के लिए अपेक्षाकृत आसान है, इसलिए मैं सुविधा के साथ जाऊंगा।

कम, बड़े, असेंबली कई छोटे लोगों की तुलना में तेज़ी से संकलित करते हैं, इसलिए मैं आपकी 'कोर' सामग्री को कंपनी.Product.dll के अंदर एक नामस्थान के रूप में शुरू करूंगा, और यदि आपको आवश्यकता हो तो इसे बाद में विभाजित करें।

Answer 2

मैं हमेशा करता हूं .Core.dll।

Answer 3

मुझे आमतौर पर ऐसे नाम होना पसंद है जो प्रत्येक असेंबली के अंदर क्या वर्णन करते हैं।

आप देखते हैं, अगर आप कुछ नाम करते हैं। तो, फिर एक बड़ी टीम पर, यह बहुत जल्दी बढ़ सकता है क्योंकि लोग उस असेंबली में बहुत आम बात डालते हैं।

तो, मुझे लगता है कि वास्तव में एक मूल असेंबली नहीं होनी चाहिए।

Answer 4

मैंने उपयोग किया है। कोर, फ़्रेमवर्क, और कॉमन।

Answer 5

एक मैं सबसे आम का उपयोग करें और प्यार करने के लिए क्योंकि मैं अन्य लोगों का उपयोग यह Root

है मैं आम तौर पर

CompanyName.Root 

या

SomethingMeaningfulToMe.Root 

Answer 6

करूँगा नहीं दिख रहा है लगता है हम इस मॉडल का उपयोग करते हैं:

• Company.Core.dll
• कंपनी.WinControls.dll
• कंपनी.WebControls।dll
• Company.Product.Core.dll
• Company.Product.WinControls.dll
• Company.Product.WebControls.dll

आदि

Answer 7

इन सभी "रूट", " कोर "," आम "और इतने पर वास्तव में खराब नामकरण-सम्मेलन हैं।

आम सामान नेट, string, int और अन्य चीजें हैं जो "मूल" या "आम" हैं जड़ System -namespace में निहित में की तरह, जड़ नाम स्थान में होना चाहिए।

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

System.Security में सामान्य सुरक्षा-चीजें हैं, उदाहरण के लिए System.Xml को इसके बारे में जानने की आवश्यकता नहीं है, जब तक कि आप उस कार्यक्षमता को स्पष्ट रूप से नहीं चाहते हैं।

System.Security.Cryptography उप-नामस्थान है। क्रिप्टोग्राफी सुरक्षा है, लेकिन सुरक्षा स्पष्ट रूप से क्रिप्टोग्राफी नहीं है। में माता पिता के नाम स्थान है और implictly उसकी पेरेंट अंदर सभी वर्गों का उपयोग कर सकते

इस तरह System.Security.Cryptography में पूर्ण जानकारी है।

मैं कहूंगा कि System.Core.dllमाइक्रोसॉफ्ट के पक्ष पर पर्ची-अप था। वे विचारों या डीएलएल-नामों से बाहर हो गए होंगे।

अद्यतन: एमएसडीएन कुछ हद तक अद्यतन article that tries to explain Microsoft's thinking on the subject है।

Answer 8

मैं भी .Core इस्तेमाल किया, विशेष रूप से .dll के लिए

इसका स्वाद के सभी एक मामले में imo, अगर जड़ नाम स्थान एक कंपनी का नाम है, मुझे लगता है .Core/रूपरेखा/आम बस की तुलना में अधिक वर्णनात्मक है कंपनी का नाम।

हालांकि यदि आप ओपनसोर्स प्रोजेक्ट की तरह कुछ पर काम कर रहे हैं, जहां डीएल/नेमस्पेस का नाम भी प्रोजेक्ट का नाम है, तो कोर /../ थोड़ा अनावश्यक हो सकता है।

.नेट फ्रेमवर्क और अन्य माइक्रोसॉफ्ट पुस्तकालयों में कई उदाहरण हैं जहां दोनों सम्मेलनों का उपयोग किया जाता है। उदाहरण के लिए एक System.dll और System.Core.dll है :)

Answer 9

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

BussinessName.Division.Layer

Answer 10

कोर बहुत सार्थक और नामकरण परिपाटी समझने में आसान है और यह किसी भी बाधा नहीं बनता है।नेट फ्रेमवर्क नेमस्पेस इसलिए यह बहुत अच्छा अभ्यास है।

I strongley प्रत्येक असेंबली में उस सेवा को प्रदान करने के लिए अनुशंसा करता है जो उस अनुप्रयोग को प्रदान करता है जो इसे उपयोग करता है और एक असेंबली में विभिन्न फ़ंक्शन डोमेन को मिश्रित नहीं करता है।

हम

CSG.Core 
CSG.Data 
CSG.Services 
... 

उपयोग कर रहे हैं कोर में हम वर्गों है कि हमारे सभी उत्पादों में इस्तेमाल किया जा करने की संभावना है शामिल कर रहे हैं: लॉगिंग, संग्रह एक्सटेंशन, जेनेरिक्स, विन्यास एक्सटेंशन, सुरक्षा, मान्यता, आदि

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

जब आप अपने नामस्थानों का नाम देते हैं तो मुझे दृढ़ता से पर नाम दिया जाता है, नामस्थान के विभिन्न स्तरों में एक ही शब्द को दोहराने से बचें। उदाहरण के लिए, निम्न से बचने:

YourCompany.Core 
YourCompany.YourProduct.Core 

या तो आपकी कंपनी में या MyProduct में नहीं बल्कि दोनों में कोर डाल दिया। यह बहुत भ्रमित हो सकता है यदि उदाहरण के लिए आपका उपयोग इस तरह दिखता है: YourCompany का उपयोग करके; YourCompany.YourProduct का उपयोग कर;

जब आप कोर टाइप करेंगे। कुछ क्लासस यह बहुत भ्रमित होगा कि यह वर्ग कहां से आया था और यदि आपके पास समान नाम वाले 2 वर्ग हैं तो यह एक संघर्ष का कारण बन जाएगा।