2009-01-24 15 views
11

एक ऑपरेशन अनुबंध को देखते हुए:एसओए डब्ल्यूसीएफ वेब-सेवाओं को डिजाइन करते समय सबसे अच्छा अभ्यास क्या है?

[OperationContract] 
void Operation(string param1, string param2, int param3); 

इसे फिर से डिज़ाइन किया जा सकता है:

[MessageContract] 
public class OperationRequest 
{ 
    [MessageBodyMember] 
    public string Param1 { get; set; } 

    [MessageBodyMember] 
    public string Param2 { get; set; } 

    [MessageBodyMember] 
    public int Param3 { get; set; } 
} 

[MessageContract] 
public class OperationResponse 
{ 
} 

[OperationContract] 
OperationResponse Operation(OperationRequest request); 

मैसेज कंट्रैक्ट के बारे में मुझे एक चीज़ यह है कि मुझे SOAP के प्रारूप पर थोड़ा अधिक स्पष्ट नियंत्रण मिलता है संदेश।

इसी तरह, मैं लगभग एक ही कोड लिख सकता हूं, लेकिन डेटाकंट्रैक्ट का उपयोग कर सकता हूं:

[DataContract] 
public class OperationRequest 
{ 
    [DataMember] 
    public string Param1 { get; set; } 

    [DataMember] 
    public string Param2 { get; set; } 

    [DataMember] 
    public int Param3 { get; set; } 
} 

[DataContract] 
public class OperationResponse 
{ 
} 

[OperationContract] 
OperationResponse Operation(OperationRequest request); 

डेटाकंट्रैक्ट के बारे में मुझे एक चीज़ यह है कि मैं IsRequired, ऑर्डर और नाम को परिभाषित कर सकता हूं।

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

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

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

उत्तर

6

XML आमतौर पर ऊंट के बने होते हैं। WSDL और XML स्कीमा दोनों तत्वों और विशेषताओं के लिए camelCasing का उपयोग करें, उदाहरण के लिए syntax और schema देखें।

क्यों SOAP अलग-अलग परिभाषित किया गया था, मुझे नहीं पता, लेकिन यह तत्वों और ऊंटों के लिए पास्कलकासिंग का उपयोग करता है, गुणों के लिए केसिंग, here देखें।

सिमिलरी, WS* चश्मा (शायद सभी) तत्वों और विशेषताओं के लिए पास्कलकासिंग का उपयोग करते हैं, here देखें। एक्सएमएल स्कीमा एक्सएमएल के लिए परिभाषित प्रकारों के सम्मेलनों के बारे में अज्ञेयवादी है।

Thomas ErlSOA पर "सेवा-ओरिएंटेड आर्किटेक्चर" सहित कई महत्वपूर्ण पुस्तकें लिखता है। अध्याय और वह ठेठ लेनदेन के विभिन्न हिस्सों के एक्सएमएल के कई उदाहरण प्रदान करता है। यह PascalCasing का उपयोग करके एक्सएमएल स्कीमा में प्रकारों और ऑब्जेक्ट सदस्यों को परिभाषित करता है जो वर्ग और संपत्ति नामकरण के लिए सामान्य रूप से सी # के सामान्य पैटर्न से मेल खाते हैं। इस प्रकार WCF डिफ़ॉल्ट पहले से ही मानकों से मेल खाते हैं।

वास्तविक संदेश नामकरण के संबंध में, कुछ सम्मेलन CamelCasing का उपयोग करते हैं और अन्य पास्कलकेसिंग का उपयोग करते हैं, इसलिए मेरी प्राथमिकता प्राथमिक भाषा आवश्यकताओं से मेल खाना है, जो WCF मामले में पास्कलसीसिंग है। और WCF डिफ़ॉल्ट कुछ उदाहरणों से मेल खाते हैं कि अनुरोध और प्रतिक्रिया संदेश कैसे लिखा जाना चाहिए, some examples here

तो एकमात्र उत्कृष्ट प्रश्न अब OperationContract, DataContract, और/या MessageContract के उपयोग के आसपास मानकीकृत करने का मूल प्रश्न है।

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

+3

यह उत्तर समुदाय विकी क्यों है? यह एक अच्छा जवाब है और vjrobinson को उस प्रतिष्ठा को प्राप्त करना चाहिए जिसके लिए वह पात्र है। –

0

मुझे लगता है कि यह ईमानदारी से परिदृश्य पर निर्भर करता है। यदि आप बस साधारण प्रकार का आदान-प्रदान कर रहे हैं [यानी। स्ट्रिंग], ऑपरेशन कंट्रैक्ट निश्चित रूप से स्वीकार्य है।

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

0

YAGNI यहां दिमाग में आता है।

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

15

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

मैं एक व्यापार एकीकरण टीम में काम करता हूं जहां हम नियमित रूप से अन्य कंपनियों के साथ एकीकृत करते हैं, (एटी & टी, कॉक्स, एक्सक्सन ...) और कभी भी एक वेब सेवा कॉल नहीं देखा है जो एक से अधिक पैरामीटर लेता है।

+0

हमारे साथ समान अभ्यास। हम सब कुछ एक अनुरोध और प्रतिक्रिया वस्तुओं में लपेटें। – Junto

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

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