हर कोई कह रहा है कि डब्लूसीएफ द्वारा .NET Remoting को कैसे बदला जा रहा है, लेकिन मुझे आश्चर्य है कि यह कितना सटीक है। मैंने कोई आधिकारिक शब्द नहीं देखा है कि रिमोटिंग को बहिष्कृत किया जा रहा है, और ऐसा लगता है कि निश्चित रूप से ऐसे परिदृश्य हैं जहां रिमोटिंग डब्ल्यूसीएफ की तुलना में अधिक समझ में आता है। ढांचे के संस्करण 4.0 में भी रिमोटिंग से संबंधित वस्तुओं या विधियों में से कोई भी बहिष्कृत नहीं किया गया है। यह भी मेरी समझ है कि सिस्टम। 3.5 और 4.0 ढांचे में जोड़ें रीमोटिंग का उपयोग करें।क्या .NET Remoting वास्तव में बहिष्कृत है?
क्या किसी के पास इसके विपरीत कोई आधिकारिक शब्द है?
लेख में, Choosing Communication Options in .NET (3.0 के लिए, के रूप में है कि उस लेख के नवीनतम संस्करण है), यह कहा गया है:
8 पार आवेदन डोमेन संचार
आप वस्तुओं के बीच संचार का समर्थन करने की जरूरत है एक ही प्रक्रिया के भीतर विभिन्न अनुप्रयोग डोमेन में, आपको .NET रीमोटिंग का उपयोग करना होगा।
अब, यह निश्चित रूप से सटीक नहीं है, क्योंकि डब्ल्यूसीएफ निश्चित रूप से एपडोमेन सीमाओं को पार करने के लिए उपयोग किया जा सकता है, लेकिन क्या यह उस परिदृश्य के लिए आधिकारिक सिफारिश दे रहा है?
अद्यतन:
क्लेमेंस, मैं समझता हूँ आप टीम है कि दोनों दूरस्थ और WCF का मालिक पर हैं, और मैं: मैं क्लेमेंस Vasters इस सवाल (जो टीम है कि दूरस्थ और WCF का मालिक पर था) भेजा मेरे पास कुछ प्रश्न हैं जो मुझे विश्वास है कि मुझे स्रोत पर जाना होगा।
सबसे पहले, मेरे पास एक सवाल है कि रिमोटिंग दूर हो रही है या नहीं। विशेष रूप से, हमारे पास एक बड़ा अनुप्रयोग है जो इन-प्रोसेस क्रॉस-एपडोमेन संचार के लिए बड़े पैमाने पर रिमोटिंग का उपयोग करता है, और मैं सोच रहा था कि रिमोटिंग के इस उपयोग को "विरासत" माना जाता है। यदि हां, तो AppDomain.CreateInstance और दोस्तों को कुछ और के साथ बदल दिया जाएगा?
दूरस्थ नेट फ्रेमवर्क का हिस्सा है और इस तरह के रूप में यह दूर नहीं जा रहा है:
यह उसका जवाब है। कॉम विंडोज एनटी 3.5/विंडोज 95 के बाद से विंडोज में रहा है और दूर नहीं चला है और मुझे नहीं लगता कि जल्द ही कभी भी जा रहा है।
उस ने कहा, रिमोटिंग में बहुत कम विकास निवेश चल रहा है। डब्ल्यूसीएफ प्रबंधित कोड के लिए रिमोटिंग और सप्लांट्स COM/DCOM का उत्तराधिकारी है।
प्रक्रिया के लिए, क्रॉस-एपडोमेन संचार रिमोटिंग सीएलआर का संचार करने का मूल तरीका है। यदि आप बड़ी मात्रा में डेटा पंप करने या कम समय में बहुत से संदेशों को पंप करने के प्रदर्शन मुद्दों को देख रहे हैं, तो आपको डब्ल्यूसीएफ और नेट नामांकित पाइप बाइंडिंग पर गंभीर नजर डालना चाहिए।
देखें http://stackoverflow.com/questions/1295353/why-am-i-seeing-slower-performance-here-from-wcf-than- इस सवाल के लिए क्यों डब्लूसीएफ रिमोटिंग से इतना धीमा है मेरी विशिष्ट स्थिति – Mark
रिमोटिंग आंतरिक है।नेट, और यह भूमिका निभाता है और यह कैसे काम करता है इसका विवरण * आवश्यक .NET * में डॉन बॉक्स और क्रिस सेल द्वारा पाया जा सकता है। हालांकि, यह अलग-अलग होता है जब अंतर-घटक संचार अविश्वसनीय या धीमा होता है, और व्यावहारिक रूप से सभी परिवहन - यहां तक कि एक गीगाबिट लैन - इन-प्रोसेस मैसेजिंग की तुलना में अविश्वसनीय और धीमी है। जब लोग डब्ल्यूसीएफ धीमे होने के बारे में बात करते हैं, तो वे आमतौर पर वेब सेवाओं के बारे में सोच रहे हैं। यदि आप इन-प्रोसेस कॉमम्स के लिए उनका उपयोग करने का प्रयास करते हैं तो वेब सेवाएं * बहुत धीमी होती हैं। हालांकि, वे धीमी और अविश्वसनीय कनेक्शन सहन करने और इन स्थितियों में अच्छी तरह से सेवा करने के लिए डिज़ाइन किए गए हैं। –
@ पीटर: जानकारी के लिए धन्यवाद, लेकिन आपकी कुछ धारणाएं पूरी तरह से गलत हैं। एक, वह रिमोटिंग धीमा या अविश्वसनीय है। यह। यह बहुत तेज है, और बहुत भरोसेमंद (निश्चित रूप से विश्वसनीय चैनलों पर)। दूसरा यह है कि "वेब सेवाएं" (जो भी इसका मतलब है) धीमी है। वे नहीं हैं। बेशक, नेटवर्क पर किसी भी चीज की तुलना में कुछ भी प्रक्रिया तेज हो रही है, लेकिन यह सवाल यह नहीं है कि यह सवाल क्या है ... – Mark