अनुरोध/प्रतिक्रिया पैटर्न

Question

कुछ उद्यम की तरह परियोजना में (.NET, WCF) मैंने देखा है कि सभी सेवा अनुबंध एक भी Request पैरामीटर स्वीकार करते हैं और हमेशा Response वापसी:

[DataContract] 
public class CustomerRequest : RequestBase { 
     [DataMember] 
     public long Id { get; set; } 
} 

[DataContract] 
public class CustomerResponse : ResponseBase { 
     [DataMember] 
     public CustomerInfo Customer { get; set; } 
} 

जहां RequestBase/ResponseBase आम सामान शामिल त्रुटि कोड, संदर्भ, इत्यादि जैसे सेवा विधियों और प्रॉक्सी दोनों की निकायों को कोशिश/पकड़ में लपेटा जाता है, इसलिए त्रुटियों की जांच करने का एकमात्र तरीका ResponseBase.ErrorCode (जो गणना है) को देख रहा है।

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

Answer 1

जिस पैटर्न के बारे में आप बात कर रहे हैं वह अनुबंध प्रथम विकास पर आधारित है। हालांकि, यह आवश्यक नहीं है कि आप डब्लूसीएफ में त्रुटि ब्लॉक पैटर्न का उपयोग करें, फिर भी आप त्रुटि एक्सएमएल ब्लॉक का उपयोग करने के बजाय, फ़ॉल्टेक्सेप्शन को क्लाइंट पर वापस फेंक सकते हैं। त्रुटि ब्लॉक का उपयोग बहुत लंबे समय से किया गया है और इसलिए, बहुत से लोग इसके उपयोग के आदी हैं। इसके अलावा, अन्य प्लेटफार्म डेवलपर्स (उदाहरण के लिए जावा) गलती के बारे में परिचित नहीं हैं, भले ही यह एक उद्योग मानक है।
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

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

अनुरोध-उत्तर के पैटर्न के लाभ हैं:

• आप अपने अनुरोध और आधार वस्तुओं से की सभी प्रतिक्रियाओं के वारिस कर सकते हैं जहां सामान्य गुणों के लिए स्थिरता (उदाहरण के लिए त्रुटि ब्लॉक) बनाए रख सकते हैं।
• वेब सेवाओं को प्रकृति द्वारा जितना संभव हो उतना कम दस्तावेज की आवश्यकता होती है। यह पैटर्न बस इतना ही अनुमति देता है। उदाहरण के लिए public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request); जैसे विधि को क्लाइंट डिफ़ॉल्ट रूप से पता चलेगा कि क्या पास करना है और वे क्या प्राप्त कर रहे हैं, साथ ही, जब वे अनुरोध बनाते हैं, तो वे देख सकते हैं कि क्या आवश्यक है और वैकल्पिक क्या है। मान लें कि इस अनुरोध में वाहक [फ्लैग एनम] (आवश्यक), स्टार्टडेट (आवश्यक), एंडडेट (आवश्यक), मूल्य श्रेणी (वैकल्पिक), मिनीसेट्स उपलब्ध (विकल्प), आदि जैसे गुण हैं ... आपको बिंदु मिलता है।
• जब उपयोगकर्ता को प्रतिक्रिया मिली, तो इसमें सामान्य वापसी ऑब्जेक्ट की तुलना में बहुत अधिक डेटा हो सकता है। त्रुटि ब्लॉक, ट्रैकिंग जानकारी, जो कुछ भी, अपनी कल्पना का उपयोग करें।
  BusScheduleResponse उदाहरण में, यह कई वाहकों के लिए बस शेड्यूल जानकारी के एकाधिक Arrays वापस कर सकता है।

उम्मीद है कि इससे मदद मिलती है।

सावधानी का एक शब्द। भ्रमित न हों और सोचें कि मैं अपना खुद का [MessageContract] एस उत्पन्न करने के बारे में बात कर रहा हूं। आपके अनुरोध और प्रतिक्रियाएं डेटाकंट्रैक्ट हैं। मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि मैं आपको भ्रमित नहीं कर रहा हूं। डब्ल्यूसीएफ में किसी को भी अपना संदेश कंट्रैक्ट नहीं बनाना चाहिए, जब तक कि ऐसा करने का वास्तव में कोई अच्छा कारण न हो।