2009-11-19 15 views
7

मैं यह तय करने की कोशिश कर रहा हूं कि मेरे आईओसी कंटेनर को समाहित करने के लिए अतिरिक्त प्रयासों को पार करना है या नहीं। अनुभव मुझे बताता है कि मुझे अपने ऐप्स और किसी भी तृतीय-पक्ष घटक के बीच encapsulation की एक परत डालना चाहिए। मुझे नहीं पता कि यह ओवरकिल पर सीमा है या नहीं।क्या मुझे अपने आईओसी कंटेनर को समाहित करना चाहिए?

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

स्पष्ट होने के लिए, मैं पंजीकरण और प्रकार के संकल्प के समावेशन पर विचार कर रहा हूं। मुझे लगता है कि यह संकल्प को समाहित करने के लिए कोई ब्रेनर नहीं है - मुझे उम्मीद है कि कंटेनर को एक सहायक/उपयोग वर्ग का प्रतिनिधि होना आम बात है।

संपादित करें:

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

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

मैं करने के लिए देख रहा हूँ:

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

मुझे पता है यह एक सा व्यक्तिपरक है, इसलिए पेशेवरों/विपक्ष उपयोगी हो सकता है

धन्यवाद!

+1

यह हो गया है। (.NET के लिए, कम से कम।) [सामान्य सेवा लोकेटर लाइब्रेरी] (http://www.codeplex.com/CommonServiceLocator) किसी भी मामले में मैं श्री Knesek से सहमत हूं। आपको आमतौर पर केवल अपने शीर्ष-स्तरीय वर्ग में अपने कंटेनर पर निर्भरता की आवश्यकता होती है। – TrueWill

+0

जो मैं प्राप्त करने की कोशिश कर रहा हूं उसके लिए ओवरकिल जैसा लगता है। मैं बस बदलाव के प्रभाव को कम करना चाहता हूं, क्या मुझे कंटेनरों को बदलने के लिए चुनना चाहिए (मेरी वर्तमान परियोजना में, या भविष्य की परियोजनाओं में)। मैं इसे पूरा करने के लिए _another_ तृतीय-पक्ष लाइब्रेरी पेश नहीं करना चाहता हूं। –

+0

संबोधित substaintially uin http://davybrion.com/blog/2009/11/integrating-your-ioc-container-with-agatha/ –

उत्तर

7

बाद में ऐसा करें, और केवल तभी जब आपको वास्तव में आईओसी कंटेनर बदलने की आवश्यकता हो।

एक आईओसी कंटेनर चुनें जो गैर-आक्रामक है। यही वह जगह है जहां वस्तुओं को एक-दूसरे से जोड़ा जा रहा है, आईओसी कंटेनर पर कोई निर्भरता नहीं है। इस मामले में, encapsulate करने के लिए कुछ भी नहीं है।

यदि आपको एक आईओसी कंटेनर चुनना है जिसके लिए आपको कंटेनर पर निर्भरता है, तो आप सबसे सरल निर्भरताओं/एपीआई के साथ एक चुन सकते हैं। यदि आपको इस आईओसी कंटेनर को प्रतिस्थापित करने की आवश्यकता है (और आप शायद नहीं करेंगे), तो एडेप्टर को कार्यान्वित करें जो पुराने एपीआई को पुराने ए को पुल करता है।

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

संपादित करें:

  1. आगंतुक कार्यान्वयन कि आईओसी विन्यास लिखते थे के साथ बिल्डर पैटर्न की एक अपेक्षाकृत जटिल कार्यान्वयन डिजाइनिंग:

    मैं या तो की गारंटी प्रकार- सुरक्षा कम करने का एक तरीका नहीं दिख रहा है फाइलें, या समकक्ष कुछ।

  2. एक प्रकार-सुरक्षित आईओसी कॉन्फ़िगरेशन डीएसएल लागू करना। (मेरी पसंद अगर मेरे पास कई ऐप थे जिनके लिए स्वीकार्य आईओसी कंटेनर आवश्यक थे।)
+0

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

+0

इसके अतिरिक्त, मैं वर्तमान आईओसी कंटेनरों के इंटरफेस के _any_ से पूरी तरह से संतुष्ट नहीं हूं, इसलिए मुझे नहीं पता कि मैं चाहता हूं कि मैं इसे निर्देशित करना चाहता हूं। –

+1

@Ryan: जबकि मैं एक्सएमएल पर टाइप-सेफ्टी से सहमत हूं, मुझे लगता है कि आप पाएंगे कि आपके पास एक वर्ग (संभवतः एक विधि भी है) जो किसी दिए गए प्रोजेक्ट के लिए सभी पंजीकरण करता है। आपके पास मौजूद परियोजनाओं की संख्या के आधार पर, पंजीकरण को सारणी से थोड़ा लाभ मिल सकता है। – TrueWill

1

हाँ इसके लिए जाएं। यह बहुत अधिक प्रयास नहीं है और जैसा कि आप कहते हैं, यह आपको तीसरे पक्ष के घटकों से बेहतर अलगाव देता है।

इसका यह भी अर्थ है कि यदि आप कुछ बेहतर पाते हैं तो आप आसानी से आईओसी कंटेनर को स्विच कर सकते हैं। मैंने हाल ही में स्ट्रक्चरमैप के लिए Spring.net IoC कंटेनर को स्वैप करने के साथ ऐसा किया है।

ASP.NET MVC Contrib कोडप्लेक्स पर प्रोजेक्ट शुरू करने के लिए एक बहुत अच्छी जगह है। यही वह है जो मैंने अपना कार्यान्वयन बंद कर दिया।

1

केवल कुछ करने के लिए सबसे अच्छा अभ्यास है यदि इसकी वास्तविक आवश्यकता है, और कभी भी ऐसा कुछ कोड न करें जिसे आप भविष्य में कभी-कभी जरूरी समझते हैं (यह तथाकथित YAGNI -principle है)। अपने वास्तुकला ठीक है, तो आप आसानी से कंटेनर को बदल सकते हैं, तो यह वास्तव में आवश्यक हो जाना चाहिए ...

आपको लगता है कि आप लचीलापन इस तरह की जरूरत है, तो आप CodePlex पर Common Service Locator project पर लग सकता है। यह वही करता है जो आप खोजते हैं: विभिन्न आईओसी कंटेनरों के लिए एक आम मुखौटा प्रदान करना।

HTH!

+0

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

+1

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

+1

जिज्ञासा से बाहर: एक रखरखाव की आवश्यकता के रूप में किस प्रकार के आवेदन "आईओसी कंटेनर कार्यान्वयन को बदलना" होगा? और बीटीडब्ल्यू: अगर इसे अब कंटेनर को समाहित करने के लिए "न्यूनतम प्रयास" की आवश्यकता है, तो इसे भविष्य में बदलने के लिए भी कम प्रयास की आवश्यकता होगी, क्या यह वास्तव में कभी भी उत्पन्न होना चाहिए ... –

1

आईओसी कंटेनर को स्वयं encapsulating करने के बजाय, मैं आईओसी कंटेनर के साथ बातचीत के लोकस को अलग करना पसंद करते हैं। उदाहरण के लिए, एएसपी.नेट एमवीसी में, मैं आमतौर पर कंटेनर को नियंत्रक फैक्ट्री और global.aspx.cs फ़ाइल में एक्सपोजर को सीमित करता हूं, जहां यह आमतौर पर सेटअप होता है।

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

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

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

संबंधित मुद्दे