मैं डब्ल्यूसीएफ बनाम वेब एपीआई पर तकनीकी बहस का प्रबंधन कैसे करूं?

Question

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

टीम ए जो वेब एपीआई के उपयोग का समर्थन करती है, इन कारणों को सामने लाती है:

1. वेब एपीआई लेखन सेवाओं का सिर्फ आधुनिक तरीका है ( विकिपीडिया )
2. WCF HTTP के लिए एक ओवरहेड है। यह टीसीपी, और नेट पाइप और अन्य प्रोटोकॉल के लिए एक समाधान है
3. WCF मॉडल [DataContract] और [DataMember] और उन विशेषताओं के कारण POCO नहीं हैं
4. SOAP JSON की तरह पठनीय और उपयोगी नहीं है
5. JSON (HTTP पर परिवहन) की तुलना में SOAP नेटवर्क के लिए एक ओवरहेड है
6. ओवरलोडिंग का कोई तरीका नहीं

टीम B जो WCF के उपयोग का समर्थन करती है, कहती है:

1. WCF कई प्रोटोकॉल (कॉन्फ़िगरेशन के माध्यम से) का समर्थन करता है
2. WCF वितरित लेनदेन का समर्थन करता है
3. WCF के लिए कई अच्छे उदाहरण और सफलता की कहानियां मौजूद हैं (जबकि वेब एपीआई अभी भी युवा है)
4. द्वैध दो-तरफ़ा संचार के लिए उत्कृष्ट है

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

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

हमारा उपयोग ज्यादातर वेब के लिए होगा, और हम HTTP पर अपनी सेवाओं को उजागर करेंगे। कुछ मामलों में (कहें कि 5 से 10 प्रतिशत) हालांकि हमें वितरित लेनदेन की आवश्यकता हो सकती है।

अब मुझे क्या करना चाहिए? मैं इस बहस को रचनात्मक तरीके से कैसे प्रबंधित करूं?

Comments

मत भूलना, वेब एपीआई उपभोक्ताओं के लिए एक SOAP WSDL करता है जैसे एक सेवा क्लाइंट उत्पन्न करना आसान नहीं बनाता है। यदि आप कभी भी .NET क्लाइंट्स के पास जा रहे हैं, तो यह कोई बड़ी बात नहीं है क्योंकि वे आपके द्वारा लागू की गई कॉन्ट्रैक्ट ऑब्जेक्ट्स को साझा कर सकते हैं, लेकिन अन्य भाषा क्लाइंट्स को SOAP का उपयोग न करने पर मैन्युअल रूप से अपने क्लाइंट ऑब्जेक्ट बनाने की आवश्यकता होगी।

— जिमी हॉफ

यह भी याद रखें कि WCF ज्यादातर मामलों में बहुत ही शालीनता के साथ json कर सकता है

— Bill

2. "WCF मॉडल POCO नहीं हैं" जो कि बस गलत है। .NET 3.5 SP1 के बाद से आपको किसी भी विशेषता का उपयोग करने की आवश्यकता नहीं है।

— एलोन गुरिलनेक '

यह प्रश्न ऑफ-टॉपिक प्रतीत होता है क्योंकि यह सहकर्मियों के बीच एक बहस के प्रबंधन के बारे में है, न कि सॉफ्टवेयर विकास के बारे में।

— ग्रैंडमास्टरबी

विकिपीडिया "लेखन सेवाओं का आधुनिक तरीका" को परिभाषित करता है? सुनिश्चित नहीं है कि यह कैसे उपयोगी है।

— फ्रैंक हिलमैन

Answer 1

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

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

Comments

प्रिय @Philipp, सिक्का सुझाव फ्लिप के लिए धन्यवाद । लेकिन जैसा कि मैंने कहा, मैं इस मौके के फैसले पर पछतावा नहीं करना चाहता । जबकि मेरा मानना ​​है कि चपलता मायने रखती है, मैं यह भी मानता हूं कि अच्छे फैसले मायने रखते हैं।

— सईद नेमाटी

@SaeedNeamati: यदि, सभी सूचनाओं को इकट्ठा करने और तौलने के बाद, किसी भी तकनीक का स्पष्ट लाभ नहीं है, तो सिक्का उछालना निर्णय लेने का सबसे ईमानदार तरीका है। टॉस के परिणाम से कोई फर्क नहीं पड़ता, यह एक अच्छा निर्णय है, क्योंकि आपने सभी जानकारी को तौला है।

— बजे बार्ट वैन इनगेन शेनौ

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

— DXM

@SaeedNeamati प्रौद्योगिकी के संदर्भ में, इस निर्णय पर "पछतावा" जैसी कोई बात नहीं है। आप हमेशा गलतियाँ करेंगे। क्या महत्वपूर्ण है कि गलतियों का पता लगाने में सक्षम हों, उन्हें खुले तौर पर स्वीकार करें, और बेहतर के लिए निर्णय बदलें।

— स्लीपर स्मिथ

अन्य विकल्प: अंगुली की लड़ाई; कुश्ती मैच; जो व्यक्ति जोर से चिल्लाता है वह जीतता है। निश्चित रूप से ये सिक्का उछालने से बेहतर हैं? :)

— फ्रैंक हिलमैन

Answer 2

मान लें कि दोनों पक्ष अपने सभी तर्कों में 100% सही हैं, जो कि मायने रखते हैं?

WCF मॉडल [DataContract] और [DataMember] और उन विशेषताओं के कारण POCO नहीं हैं

क्या तुम्हें परवाह है? क्या आप ऐसा कुछ करने की योजना बना रहे हैं जिसमें POCO की आवश्यकता हो?

WCF वितरित लेनदेन का समर्थन करता है

फिर से यह कुछ आप उपयोग करने जा रहे हैं और निर्माण करने की आवश्यकता है यदि आपके पास नहीं है क्योंकि आपने दूसरा रास्ता लिया है?

मूल रूप से जो एक के दिल में मिलता है:

• आपकी ज़रूरत की हर चीज़ पेश करता है (यदि आपको ज़रूरत की हर चीज़ की पेशकश नहीं करनी चाहिए, जिससे आपको कम से कम काम करना पड़े)।
• कबाड़ की कम से कम राशि प्रदान करता है जिसका आप उपयोग नहीं करने जा रहे हैं, लेकिन इसके साथ-साथ आपको लगाना होगा।

किसी भी तर्क को आगे रखा गया है, जिसे आप को पूरा करने की आवश्यकता के मार्ग में नहीं है, अप्रासंगिक है और भविष्य के विस्तार पर विचार करने के लिए कुछ wiggle कमरे के साथ, अपने निर्णय में कारक नहीं होना चाहिए।

Comments

WCF डेटा सेवा मॉडल POCO हैं, केवल आवश्यकता एक [नाम] आईडी फ़ील्ड iirc है।

— मास्लो

Answer 3

मेरे दो सेंट अंदर रखो।

एक प्रबंधक के रूप में, आपको अपने टीममेट्स से याग्नी सिद्धांत को ध्यान में रखने के लिए कहना चाहिए । यह दोनों टीमों द्वारा आगे लाए गए कारणों की सूची को कम करने में मदद करेगा।

हमारा उपयोग ज्यादातर वेब के लिए होगा, और हम HTTP पर अपनी सेवाओं को उजागर करेंगे। कुछ मामलों में (कहें कि 5 से 10 प्रतिशत) हालांकि हमें वितरित लेनदेन की आवश्यकता हो सकती है।

वितरित लेनदेन में गोता लगाने के बजाय, आपको इसके बजाय मुआवजे के साथ काम करने पर विचार करना चाहिए ।

पिछली बात को ध्यान में रखना सीखने की अवस्था है। एक प्रबंधक के रूप में अपनी परियोजना की समय सीमा के आधार पर, आपको यह तय करने में सक्षम होना चाहिए कि नई तकनीक सीखना शुरू करना ठीक है या नहीं।

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

वैसे, उस व्यक्ति को जो कहता है कि " WCF मॉडल POCO नहीं हैं, क्योंकि [DataContract] और [DataMember] और उन विशेषताओं के कारण ", उसे बताएं कि POCO सामान्य रूप से डोमेन संस्थाएं हैं और यह उजागर करने के लिए सबसे अच्छा अभ्यास नहीं है। किसी भी तरह के क्लाइंट के लिए आपका डोमेन ऑब्जेक्ट, डीटीओ के लिए यही है।

Comments

फ़्लैडेड / बाहरी अनुबंध में डोमेन ऑब्जेक्ट को उजागर नहीं करने के लिए +1। सस्ती जीत के लिए कम से कम 10 बार और उनमें से 9 में एक निश्चित कॉम्स अनुबंध होने और एक डोमेन परिवर्तन का प्रबंधन करने में दर्द के कारण रिफैक्ट हो गया। वितरित लेनदेन के लिए +1, इसकी बहुत बुरी बात है ..

— user1496062

Answer 4

अब मुझे क्या करना चाहिए? मैं इस बहस को रचनात्मक तरीके से कैसे प्रबंधित करूं?

सबसे पहले, सब्जेक्टिविटी को दूर रखें। आपकी WebAPI टीम के तर्कों में, मुझे लगता है कि "Web API सिर्फ आधुनिक तरीका है" *, "WCF मॉडल POCO नहीं हैं, उन विशेषताओं के कारण" और "SOAP पठनीय और आसान नहीं है, JSON जितना सुंदर " , यदि स्पष्ट नहीं तो गलत , और निर्णय लेने में मदद नहीं करेगा।

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

दिलचस्प पठन सामग्री:

• पीवीसी 4 बनाम डब्ल्यूसीएफ वेब एपि
• WCF या ASP.NET वेब एपीआई? विषय पर मेरे दो सेंट
• WebAPI या WCF?

*: ध्यान दें कि आप इसके लिए विकिपीडिया का उल्लेख करते हैं, जहाँ प्रशस्ति पत्र है: " वेब 2.0 वेब एप्लिकेशन सेवा-आधारित वास्तुकला (SOA) से दूर चले गए हैं , ताकि SOAP- आधारित वेब सेवाओं के साथ Restful वेब संसाधनों के अधिक सामंजस्यपूर्ण संग्रह की ओर" । जब आपकी सेवा किसी वेबपृष्ठ से ली जानी हो, तो इसका उपयोग इसका एक उदाहरण है। यह भी आसानी से WCF के साथ किया जा सकता है, WebHttpBinding का उपयोग कर। यह नहीं कहता है "इसके लिए WebAPI का उपयोग करें" ।

यदि यह प्रश्न "चर्चा का प्रबंधन कैसे करें " से परे है : यदि गैर-वेब-क्लाइंट द्वारा सेवाओं का उपभोग किया जाना है, तो मैं WCF का उपयोग करूंगा, क्योंकि इसका मेटाडेटा आश्चर्यजनक रूप से आसान-टाइप किए गए क्लाइंट पीढ़ी के लिए अनुमति देता है।

Comments

इतना ही नहीं। " XYZ सिर्फ आधुनिक तरीका है " एक NULL-Argument है, जो आमतौर पर पढ़ता है " मेरे पास कोई वास्तविक तर्क नहीं है, लेकिन यह सीजन का मेरा व्यक्तिगत पसंदीदा है। "

— JensG

Answer 5

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

हमारा उपयोग ज्यादातर वेब के लिए होगा, और हम HTTP पर अपनी सेवाओं को उजागर करेंगे। कुछ मामलों में (कहें कि 5 से 10 प्रतिशत) हालांकि हमें वितरित लेनदेन की आवश्यकता हो सकती है।

फिर आप WCF में उन 5 ~ 10% वेब सेवाओं को लिखते हैं। यदि सेवा को अन्य परियोजनाओं में आंतरिक रूप से संदर्भित किया जाना है, तो कोई बहस नहीं है। क्लाइंट प्रॉक्सी बनाने के लिए WCF अनुबंध आयात करने की क्षमता का लाभ चर्चा के लिए खुला नहीं है। यह पूरे एकीकरण, दक्षता और प्रकार की सुरक्षा को एक नए स्तर पर ले जाता है।

आप लिखते हैं कि सार्वजनिक एप (शायद) / अजाक्स अनुरोधों के लिए Asp.net web api में क्या उपयोग किया जाना है।

यदि यह केवल पृष्ठ विशिष्ट अजाक्स कॉल है, तो आप बस Asp.Net MVC का उपयोग कर सकते हैं।

चुनें, उन सभी को गले न लगाएं। WCF और Asp.net वेब एप विभिन्न उद्देश्यों की पूर्ति करते हैं। कोई भी नहीं कहता है कि आप अपने फलों के सलाद में सेब और नारंगी दोनों नहीं ले सकते। एक को दूसरे के ऊपर ले जाने की कोशिश करना और उसे हर एक परिदृश्य से अलग करना सिर्फ सरासर आलस्य है।

Answer 6

हमारी टीम ने कुछ महीने पहले इसी तरह की चर्चा की थी। हमारे लिए निर्णय लेने वाला कारक नीचे आ गया कि हम प्रत्येक तकनीक का निर्माण और कार्यान्वयन कैसे करेंगे। चूंकि हम पहले से ही एमवीसी एप्लिकेशन का निर्माण कर रहे थे और डेटा बाइंडिंग के लिए नॉकआउट का उपयोग कर रहे थे, इसलिए हम एमवीवीएम का उपयोग नियंत्रकों के साथ केवल डेटा के लिए एपीआई होने के नाते प्रभावी ढंग से कर रहे थे।

इसने इस परियोजना के साथ प्रौद्योगिकियों के हमारे उपयोग को वर्गीकृत करने की अनुमति दी है:

• वेब एपीआई का उपयोग हमारे एपीआई के रूप में नॉकआउट और अजाक्स कॉल के लिए किया जाएगा, जिससे वे एमवीवीएम पैटर्न के लिए हमारी आज्ञा बनेंगे। वेब एप्लिकेशन के लिए हमारे व्यावसायिक तर्क कई वर्गों और रिपॉजिटरी और कारखानों के माध्यम से इस परत के पीछे लिपटे हुए हैं।
• WCF को तब हमारे डेटा स्टोर के लिए उपयोग किया जाता है, जो हमारे डेटाबेस से डेटा को उजागर करता है, न केवल इस वेबसाइट के लिए, बल्कि किसी अन्य साइट या सेवा के लिए जो कि उजागर डेटा का उपभोग करता है।

हालांकि यह एक लोकप्रिय या हाइपर तकनीकी प्रतिक्रिया नहीं हो सकती है, यह निर्धारित करना कि आपको पहले क्या और कैसे चाहिए या अगर तकनीक मदद करेगी तो मेरी टीम को यह तय करने में मदद मिलेगी कि किस तकनीक का उपयोग करना है।

Comments

कैसे अपने WCF परत प्रामाणिक संभालती है?

— मास्लो

Answer 7

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

यह सबसे उचित तरीका होगा। WCF और WebApi दोनों सेवाओं का एक ही वेब एप्लिकेशन में होना काफी सामान्य है, जहां दोनों अलग-अलग उद्देश्यों की पूर्ति करते हैं।

बस कुछ तर्क सही करने के लिए:

WCF मॉडल [DataContract] और [DataMember] और उन विशेषताओं के कारण POCO नहीं हैं

कई मामलों में WCF मॉडल डाटाकंट्रेक्ट / डेटामेम्बर विशेषताओं के बिना काम करते हैं ।

SOAP JSON की तरह पठनीय और उपयोगी नहीं है

यह सच नहीं है, लेकिन WCF वेब सेवाएं आमतौर पर ब्लॉटेड SOAP के बजाय सादे XML लेती हैं। यह निश्चित रूप से पठनीय है।

डब्ल्यूसीएफ के लिए एक तर्क : यदि कोई डब्ल्यूएसडीएल उपलब्ध है, तो लगभग सभी प्रौद्योगिकियों में बहुत सारे उपकरण हैं जो मेटाडेटा के बाहर समरूपता पैदा कर सकते हैं। दूसरी ओर, JSON स्कीमा अभी तक सभी व्यापक रूप से समर्थित नहीं है।

Answer 8

WCF डेटा सेवाओं के साथ लाइन क्यों नहीं चलती? अच्छा OData / वेबपी शैली WCF की शक्तियां, और JSONठीक वापस लौटने की क्षमता के साथ प्रयोज्यता । Wcf भी उतना बुरा नहीं है यदि आपके पास निम्नलिखित की तरह एक अच्छा स्वचालित wcf होस्टिंग कोड है:

https://github.com/ImaginaryDevelopment/MvcOdata

मैं कहता हूं कि वे बिल्कुल अलग नहीं हैं, सिवाय इसके कि जब हम WebApiसामने के छोर WCF data servicesपर और मध्य स्तर पर उपयोग करने के लिए गए थे , तो WebApiस्ट्रिंग जैसी साधारण चीजों पर फेंक दिया गया था या स्ट्रिंग मिलान वाले ओटाटा ऑपरेटर थे।

Answer 9

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

दूसरे शब्दों में, जब तक ग्राहक को वास्तव में कनेक्ट करने की आवश्यकता न हो, तब तक निर्णय न करें। आप वास्तव में पूरी तरह से परीक्षण की गई सेवा परत का निर्माण कर सकते हैं, वास्तव में उस पर परिवहन / स्मारक तंत्र नहीं डाल सकते हैं। काम का 95% + ढाँचा के बाहर एडेप्टर को "नीचे" किया जा सकता है।

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

नरक, यदि आपकी "वास्तविक" सेवा परत अच्छी तरह से की गई है, तो आप न्यूनतम खर्च पर कई रैपर भी आज़मा सकते हैं।

यह वैसे भी हठधर्मिता का जवाब है। अभ्यास में , आप लेने के लिए चाहते हो सकता है सबसे सरल अभी भी इस पर अपनी निर्भरता को सीमित करने और एक के रूप में सख्ती से यह इलाज लेकिन, - शेल्फ से उपकरण जल्दी और बार-बार एकीकरण परीक्षण की सुविधा के लिए बस से अधिक पतली संचार परत असली सेवाएं।

---

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

Comments

जाहिर है, इस जवाब में खेल के लिए बहुत देर हो चुकी है - लेकिन, मैं वास्तव में आश्चर्यचकित था कि कोई भी लोकप्रिय जवाब हठधर्मिता से

— पुनर्जीवित

Answer 10

इसलिए अब मैं उसी विकल्प का सामना कर रहा हूं, मैंने अपने आप से पूछा कि हमारी टीम इस समय WCF से सुविधाओं का सबसेट क्या उपयोग कर रही है। क्या हम अलग-अलग प्रोटोकॉल का उपयोग करते हैं? क्या हम लेनदेन सहायता का उपयोग करते हैं? नहीं (हालांकि हम कस्टम अंतिम स्थिरता तंत्र का उपयोग करते हैं)। क्या हम डुप्लेक्स का उपयोग करते हैं? नहीं।

हम Web API का उपयोग क्यों करना चाहते हैं? आसान फ्रंटएंड इंटीग्रेशन (अभी मौजूद अतिरिक्त सर्विस लेयर को हटाता है), ग्राहकों को रिप्लाई को पुश करने के लिए सिग्नलआर, जीईटी के लिए कैशिंग।

हो सकता है, कोई अन्य कारण पा सकता है :) साथ ही, WCF के साथ रहने के कारण।

Comments

ओपी डब्ल्यूसीएफ बनाम वेब एपीआई के बारे में नहीं पूछ रहा है, ओपी पूछ रहा है कि उनकी टीम को आंतरिक, तकनीकी बहस का प्रबंधन कैसे करना है। आपका उत्तर प्रश्न के व्यापक भाग को याद करता है।

Answer 11

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

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

Answer 12

मैं पूछता हूं कि आपको किस मॉडल की सहभागिता की आवश्यकता है? क्या आपका वांछित बाहरी इंटरफ़ेस RPC या REST से मिलता जुलता है? मेरे अनुभव में यह आमतौर पर कहीं न कहीं एक या दूसरे के बीच होता है।

क्या आप .Net में अन्य परियोजनाओं के लिए अपनी स्वयं की सेवाओं का उपभोग कर रहे हैं? यह शायद सबसे अधिक खुलासा करने वाला प्रश्न है जो आप पूछ सकते हैं। WCF का फायदा यह है कि आप अपने इंटरफेस को एक अलग वर्ग के पुस्तकालय में रखने में सक्षम हो सकते हैं और अपने क्लाइंट को बनाने और इंजेक्ट करने में सक्षम हो सकते हैं। इसके विस्तार के रूप में, आप JSON और SOAP / WSDL दोनों बिंदुओं के साथ अपने WCF आधारित प्रोजेक्ट को माउंट कर सकते हैं, मैंने इसे किया है। WCF आपके परिभाषित इंटरफेस के खिलाफ बेहतर आश्वासन भी देता है।

यदि आपने सामान्य रूप से अन्य प्लेटफार्मों XML से क्लाइंट्स की अपेक्षा की है, तो कहा, अकेले SOAP में औसत दर्जे का ओवरहेड है जो जेन्स एंडपॉइंट्स से अधिक सरल है। यदि आप JSON / Web API रूट पर जाते हैं, तो आपको अपने एंडपॉइंट्स और API के साथ सहभागिता करने के लिए दस्तावेज़ बनाने में बहुत बेहतर बनना होगा।

सामान्य तौर पर, मैं एक साधारण एपीआई दस्तावेज़ लिखने का सुझाव दूंगा जो बताता है कि आप डेटा कैसे जमा करेंगे, और आप एकल अनुरोध ऑब्जेक्ट संरचना के लिए प्रतिक्रिया कैसे चाहते हैं। अपने परीक्षण के मामले को सबसे सार्वभौमिक तरीके से लिखें, और इसे इस तरह से दस्तावेज करें। मैं एक साधारण कर्ल स्टेटमेंट सुझाऊंगा। फिर आपके कई सदस्यों ने डब्ल्यूसीएफ और वेब एपीआई के साथ इसे लागू किया है। फिर देखें कौन सी जीत।

व्यक्तिगत रूप से, WCF के साथ कुछ अपेक्षाकृत बड़ी परियोजनाओं और कार्यान्वयनों को करने के बावजूद, मैं वास्तव में सबसे सरल कार्यान्वयन की ओर झुकता हूं जो वास्तव में JSON परिणामों और त्रुटि स्थितियों से निपटने के लिए Global.asax.cs में कुछ ओवरराइड व्यवहार का उपयोग करने के साथ सीधे WCF है। अगर किसी API के प्रलेखन में कर्ल स्टेटमेंट शामिल हैं, और आप अपने API की कार्यक्षमता को कर्ल उदाहरणों के साथ प्रयोग कर सकते हैं, तो क्लाइंट्स के लिए किसी भी भाषा में कार्यान्वित होना आसान हो जाता है जो वेब इंटरफेस का समर्थन करता है। यह वास्तव में है जहां डब्ल्यूसीएफ नीचे गिरना शुरू होता है। अज्ञेय प्रलेखन के साथ एक अच्छी तरह से परिभाषित एपीआई होने पर विदेशी प्रणालियों से निपटने के दौरान स्वचालित टूलींग के साथ संरचनाएं होने से बेहतर है। अन्य प्लेटफार्मों से उन प्रणालियों के उपभोक्ता के रूप में बोलना।

इससे परे एक बात, अपने ग्राहक को दो विषम भाषाओं में लागू करना है। C # में एक क्लाइंट करें, लेकिन Node.js या Python में भी एक करें और देखें कि वे वास्तव में कितने अच्छे हैं। अकेले व्यायाम आपको अपने एपीआई में ढीले सिरों को बाहर निकालने में मदद करेगा।