क्लास इंटरफेस को .NET क्लास लाइब्रेरी में कहां रखा जाना चाहिए?

Question

मैं डेवलपर्स की राय/प्रथाओं के लिए उत्सुक हूं कि क्लास इंटरफेस कहां होना चाहिए, आदर्श रूप से, एक .NET क्लास लाइब्रेरी में रखा जाना चाहिए। क्या उन्हें समाधान के भीतर अपनी समर्पित पुस्तकालय में शामिल किया जाना चाहिए जैसे MyCompany.AccountPackage.Interfaces?

क्या उनके पास अपना नामस्थान होना चाहिए उदा। MyCompany.AccountPackage.MasterAccounts.Interfaces?

कोई अन्य विचार/राय की सराहना की?

क्या कोई अच्छी मार्गदर्शिका है कि नेट लाइब्रेरी (या यहां तक ​​कि बेहतर, समाधान) को कैसे व्यवस्थित किया जाए, सामान्य रूप से दिखाया जा रहा है कि मानक पुस्तकालय में कौन से वर्ग/इंटरफेस को आम तौर पर उजागर किया जाना चाहिए।

धन्यवाद, डी।

Answer 1

लघु जवाब:

इंटरफेस, जहां वे लागू किया जाता है के पास होना चाहिए।

कम से कम बीसीएल में से कुछ यह करता है - IEnumerable<T>System.Collections.Generic नामस्थान में रहता है, उदाहरण के लिए।

---

थोड़ा लंबा उत्तर:

यह क्या इंटरफेस का उद्देश्य है पर निर्भर करता है।

क्या यह तीसरे पक्ष के लिए प्लग-इन इंटरफेस (ए-ला प्रदाता मॉडल या एमईएफ) प्रदान करना है?

यदि ऐसा है, तो एक अलग असेंबली समझ में आ सकती है, इसलिए तीसरे पक्ष द्वारा आयात किए जाने वाले सभी को यह असेंबली है।

क्या यह परीक्षण और आईओसी उद्देश्यों के लिए आंतरिक है?

मैं तर्क दूंगा कि कार्यान्वयन के करीब इसे समझना, संगठनात्मक रूप से और इंटरफेस के साथ कोड को समन्वयित रखने में मदद करने के लिए।

Answer 2

निम्नलिखित पोस्ट देखें:

1. इन इंटरफेस कई विधानसभाओं द्वारा उपयोग किया जाएगा:

   Proper .NET DLL structure for app

   और, आम तौर पर निम्नलिखित सवालों के जवाब देने की कोशिश?

2. क्या आप कोई भी कम कर सकते हैं। असेंबली और संदर्भों का?

3. क्या आप एकल असेंबली में असंबद्ध इंटरफेस को शामिल करने की कोशिश कर रहे हैं, बस डीएल गिनती को कम करने के लिए?

4. क्या आपने स्केलेबिलिटी और रखरखाव के बारे में सोचा था?

Answer 3

यह लगता है कि इस सवाल का जवाब नहीं बल्कि में प्रासंगिक है यह निर्भर करता है कि क्या इंटरफेस के लिए कर रहे हैं और कैसे वे अपने पुस्तकालय की वास्तुकला में फिट है।

ऑब्जेक्ट मॉडल

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

जेनेरिक उपयोग

आप एक इंटरफेस नेट के System.Collections.Generic नाम स्थान है, जो कई स्थानों में फिर से इस्तेमाल किया जा जा रहे हैं में पाए जाने वाले के समान बनाने पर इरादा कर रहे हैं; तो मैं इसे कम डाउन रखने का सुझाव दूंगा ताकि एकाधिक प्रोजेक्ट इंटरफ़ेस तक पहुंच और कार्यान्वित कर सकें। हालांकि, इसका मतलब यह नहीं है कि आप एक ही प्रोजेक्ट के भीतर इंटरफ़ेस को स्वयं लागू नहीं कर सकते हैं। उस स्थिति में, यह सब उस असेंबली के भीतर होने का इरादा रखता है।

अन्य उपयोग

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

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

Answer 4

अधिकांश स्थितियों में: यह निर्भर करता है।

लेकिन 99% मामलों में मैंने अपने स्वयं के असेंबली में इंटरफेस लगाए, कड़े इंटरफ़ेस निर्भरताओं को रोकने के लिए लॉजिकल इकाइयों में समूहित किया। पूर्व दिनों में मैंने बस इसे रखा जहां पहला कार्यान्वयन था। यह एक कसकर युग्मित गड़बड़ी में बढ़ गया जो बाद में विभाजित करना असंभव था।

यदि आप ढीले युग्मन के लिए अभ्यास/प्रयास करते हैं, तो मैं अलग-अलग असेंबली में इंटरफेस को आगे बढ़ाने का सुझाव देता हूं। मैं केवल करने के लिए पसंद में शामिल हैं:

• इंटरफेस,
• enumerations
• स्थिरांक
• इंटरफेस (विशिष्ट कार्यान्वयन पर निर्भर करता है नहीं) के लिए विस्तार तरीकों
• "स्थिर" वर्गों और structs (अर्थातउन है कि कभी कभी नहीं बदल जाएगा या प्राप्त की जा)

"इंटरफेस विधानसभाओं" में और केवल संदर्भ के लिए:

• अन्य "इंटरफेस विधानसभाओं"
• "उपकरण विधानसभाओं" (जो themself केवल शामिल करना चाहिए एक्सटेंशन विधियों, स्थिरांक जैसे स्थिर सामान)

यह आंतरिक रूप से उपयोग किए जाने वाले इंटरफेस पर लागू नहीं होता है जो केवल एक असेंबली में उपयोग किया जाता है (जो इंटरफेस का 1% होगा)।

केवल कार्यान्वयन कि इंटरफेस से एक है के रूप में ही विधानसभा में शामिल किया जा सकता है, कि:

• अन्य गैर इंटरफ़ेस विधानसभाओं पर निर्भर नहीं करता (आप के लिए सामान शामिल करने के लिए नहीं करना चाहते हैं एक इंटरफेस असेंबली का उपयोग करें जिसे केवल एक कार्यान्वयन के लिए जरूरी है जिसे आप उपयोग नहीं करना चाहते हैं)।
• डिफ़ॉल्ट किसी तरह का या कोई सेशन कार्यान्वयन

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

क्यों? इस तरह आपकी असेंबली केवल स्थिर असेंबली पर भरोसा करती है और कसकर युग्मित नहीं होती है। यदि आप निर्भरता इंजेक्शन का उपयोग करने की योजना बनाते हैं तो यह भी पसंदीदा तरीका है।

नेमस्पेस:

आप इंटरफेस की एक उप-नाम स्थान में कार्यान्वयन रखना चाहिए। तो, अपने उदाहरण लेने के लिए, मेरा सुझाव चाहते हैं:

• MyCompany.AccountPackage.MasterAccounts
• में इंटरफ़ेस डाल इस इंटरफेस के लिए विस्तार के तरीकों, अन्य स्थिर सामान डाल भी MyCompany.AccountPackage.MasterAccounts
• में में एक ठीक से नामित एक कार्यान्वयन डाल उप-नामस्थान MyCompany.AccountPackage.MasterAccounts.SQLMasterAccounts या बस MyCompany.AccountPackage.MasterAccounts.Implementation।

क्यों?

कार्यान्वयन पक्ष से इसका मतलब है, आपको using MyCompany.AccountPackage.MasterAccounts.Interfaces का उपयोग किए बिना सभी इंटरफेस और एक्सटेंशन सामान मिलते हैं।

ग्राहकों की तरफ से इसका मतलब है कि आपको कार्यान्वयन असेंबली में इंटेलिजेंस से बहुत अधिक विकल्पों से बचाया जाएगा (जिसमें अन्य कार्यान्वयन असेंबली शामिल नहीं होनी चाहिए), फिर भी मुख्य असेंबली में कार्यान्वयन तक आसानी से पहुंच है, जहां आप उपयोग करने के लिए ठोस कार्यान्वयन का चयन करते हैं।