2010-06-29 12 views
15

आइए हम कहें कि मैं किसी तृतीय-पक्ष लाइब्रेरी तक पहुंच रहा हूं, जिसके लिए प्रलेखन कहता है कि मैं pInvoke का उपयोग कर सकता हूं या इंटरऑप लाइब्रेरी बना सकता हूं और COM का उपयोग कर सकता हूं। इन दो तकनीकों के बीच क्या अंतर है, और मैं दूसरे पर एक क्यों चुन सकता हूं?PInvoke और COM Interop के बीच क्या अंतर है?

उत्तर

12

पी/इनवॉक का उपयोग सादे-सी एपीआई (जैसे अधिकांश Win32 एपीआई) को कॉल करने के लिए किया जाता है। COM इंटरऑप का उपयोग COM ऑब्जेक्ट्स को कॉल करने के लिए किया जाता है।

आप एक सी एपीआई के चारों ओर एक सी ++ COM wrapper बना सकते हैं और फिर एपीआई कॉल की संख्या अपेक्षाकृत अधिक है तो आप अपने रैपर को कॉल करने के लिए COM इंटरऑप का उपयोग कर सकते हैं (और आप COM wrapper का उपयोग केवल एक या दो कॉल में encapsulate करने के लिए कर सकते हैं)। ऐसा इसलिए है क्योंकि प्रबंधित-देशी इंटरऑप अपेक्षाकृत महंगा हो सकता है और संक्रमण की संख्या को कम करना अच्छा होता है। हालांकि वास्तव में मैं कहूंगा कि रैपर बनाने के लिए सी ++/सीएलआई का उपयोग करना शायद सी # पक्ष के लिए थोड़ा अधिक अनुकूल होगा (उदाहरण के लिए SlimDX पर, उदाहरण के लिए, जो एक COM API (DirectX) के आसपास एक सी ++/सीएलआई रैपर है)।

यह कहकर कि, जब तक कि आपके पास कोई विशिष्ट प्रदर्शन समस्या न हो, मैं केवल उस एपीआई के लिए जो भी विधि अधिक प्राकृतिक हो, उसका उपयोग करूँगा: यदि यह एक सीपीआई है (जैसे Win32 API है) तो पी का उपयोग करें/आह्वान। यदि यह COM-आधारित है, तो COM इंटरऑप का उपयोग करें।

+0

तो क्या आप कह रहे हैं कि हुड के तहत, COM interops स्वयं pinvokes कर रहे हैं? और वह COM सिर्फ एक दोस्ताना आवरण है? – Grant

+2

नहीं, COM इंटरऑप और पी/Invoke अलग हैं और एक दूसरे के मामले में लागू नहीं किया गया है। मैं अपने दूसरे पैराग्राफ में जो कह रहा था वह यह है कि यदि सी एपीआई "चतुर" है और उसे कई फ़ंक्शन कॉल की आवश्यकता होती है, तो आप COM wrapper (C++ में) बना सकते हैं और प्रबंधित * की संख्या को कम करने के लिए * सी # से रैपर * कॉल कर सकते हैं। मूल संक्रमण। मुझे संदेह है कि आपकी लाइब्रेरी के लिए प्रलेखन सुझाव दे रहा है। –

3

PInvoke निष्पादन प्रक्रिया में बाहरी कोड लाने के लिए गतिशील लिंकिंग तंत्र का उपयोग करता है। डायनामिक लिंकिंग लाइब्रेरीज़ (डीएलएल) में कॉलिंग एप्लिकेशन के समान लक्ष्य आर्किटेक्चर होना चाहिए, इसलिए 64-बिट से 32-बिट या इसके विपरीत क्रॉस कॉल करने की कोई क्षमता नहीं है। इसके बजाय डीएलएल को कॉलर के पता स्थान में मैप किया गया है और प्रक्रिया में निष्पादित किया गया है।

COM, DCOM, COM +, और ActiveX सभी इंटरप्रोसेस संचार पुस्तकालयों पर आधारित हैं, लेकिन कभी-कभी एक साधारण डीएलएल लोड में भंग हो सकते हैं। कॉम से जुड़े ऑब्जेक्ट्स संबंधित हैं, लेकिन कोर्बा ऑब्जेक्ट्स के समान नहीं हैं, लेकिन कोर्बा ने अपना ऑब्जेक्ट लोकेटर विकसित किया है, जबकि COM कार्यान्वयन अभी भी संक्षेप में सूर्य माइक्रोसिस्टम्स आरपीसी और एक्सडीआर पुस्तकालयों पर आधारित है जो COM की ऑब्जेक्ट उन्मुख सुविधाओं के लिए एक्सटेंशन के साथ हैं। COM ऑब्जेक्ट्स का संदर्भ डीएलएल द्वारा नहीं किया जाता है, लेकिन एक GUID द्वारा जिसका उपयोग ऑब्जेक्ट क्लास को देखने और इसके इंटरफेस से पूछताछ करने के लिए किया जाता है। ऑब्जेक्ट कोड आमतौर पर एक अलग प्रक्रिया में चलता है, और संभवतः एक अलग सर्वर पर चलता है।

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