डब्ल्यूटीसी वेब सेवा

Question

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

मैं आपसे क्या चाहता हूं, यहां कुछ सर्वोत्तम अभ्यासों पर सलाह दी गई है।

class Order 
{ 
    int CreatedBy { get; set; } 
    DateTime CreatedOn { get; set; } 
    string Description { get; set; } 
    int Id { get; set; } 
    string Name { get; set; } 
} 

हमारे एपीआई मान लिया जाये कि करने के लिए एक उपभोक्ता, अद्यतन बनाएँ और एक आदेश प्राप्त की अनुमति देता है, हम निम्नलिखित DTOs बनाया है:

उदाहरण के लिए, निम्नलिखित सरल मॉडल पर विचार करें। सादगी के लिए डेटामेम्बर और डेटाकंट्रैक्ट विशेषताएं समाप्त हो गई हैं।

बनाएं विधि: एक उपयोगकर्ता ईद और CreatedOn गुण निर्दिष्ट नहीं कर सकते, तो डीटीओ इस तरह दिखता है:

class CreateOrderData 
{ 
    int CreatedBy { get; set; } 
    string Description { get; set; } 
    string Name { get; set; } 
} 

अद्यतन विधि: एक उपयोगकर्ता निर्दिष्ट नहीं कर सकते ईद , बनाया गया और बनाया गया गुण, इसलिए डीटीओ इस तरह दिखता है:

class UpdateOrderData 
{ 
    string Description { get; set; } 
    string Name { get; set; } 
} 

विधि प्राप्त करें: एक उपयोगकर्ता, आदेश के लिए सब कुछ देखने के लिए सक्षम होना चाहिए ताकि डीटीओ इस तरह दिखता है:

• :

  class OrderData 
  { 
      int CreatedBy { get; set; } 
      DateTime CreatedOn { get; set; } 
      string Description { get; set; } 
      int Id { get; set; } 
      string Name { get; set; } 
  } 
  

  तो यहाँ मेरी सवाल कर रहे हैं मान लें कि ऑर्डर मॉडल में और अधिक गुण हैं और उन गुणों में से कई को "बनाएं" और "अपडेट" डीटीओ के बीच साझा किया जाता है, क्या यह समझता है कि ये कक्षाएं सामान्य बेस क्लास से बढ़ती हैं? यदि हां, तो क्या "प्राप्त करें" डीटीओ (ऑर्डरडेटा) उस कक्षा से भी बढ़ाना चाहिए? अगर हम ऐसा करते हैं, तो क्या यह इन डीटीओ को एक-दूसरे पर निर्भर नहीं करता है?

• यदि सभी गुण "बनाएं" और "अपडेट" डीटीओ के बीच आम हैं, तो क्या हमें अभी भी दो अलग-अलग डीटीओ बनाना चाहिए? यदि हां, क्यों? यदि नहीं, (यह अभी सिर्फ एक नामकरण प्रश्न है) "CreateOrUpdate" डीटीओ को क्या कहा जाना चाहिए ताकि नाम "प्राप्त करें" डीटीओ से स्पष्ट रूप से अलग हो?

• क्या सभी डेटा डीटीओ को "डेटा" या "डेटाऑब्जेक्ट" या "डीटीओ" जैसे कुछ प्रत्यय करना ठीक है?

• क्या हम यहां सही रास्ते पर हैं? यदि नहीं, तो यह डिज़ाइन बेहतर कैसे बनाया जा सकता है?

अद्यतन:

मुझे लगता है मैं DTOs में विरासत पसंद नहीं है क्योंकि आधार वर्ग भी डबल्यूएसडीएल में उजागर किया जाएगा और ग्राहक इसे देख सकते हैं और यह दृष्टांत जो गंदा लगता है में सक्षम हो जाएगा मेरे लिए (इसे देखें: WCF Serialization with object inheritance?)। विरासत के बजाय सामान्य गुणों को लागू करने के लिए डीटीओ में इंटरफेस का उपयोग करने के बारे में कैसे? चूंकि डीटीओ में उनमें कोई व्यवहार नहीं होना चाहिए, इसलिए हम विरासत को बदलकर ज्यादा खो नहीं रहे हैं।

Answer 1

चूंकि यह व्यक्तिगत वरीयताओं के बारे में बहुत है, मैं इस करना होगा ..

1. के बाद से है कि ठोस में एल का पालन नहीं होता मैं एक आम आधार वर्ग नहीं बनाता। यदि आप DRY के बारे में चिंतित हैं, तो आप इसके बजाय एकत्रीकरण बना सकते हैं।

2. यदि सभी गुण सामान्य हैं, तो यह उस वस्तु को ले जाने के लिए समझ में आता है, जो ऑब्जेक्ट लेता है, ऑर्डर डीटीओ क्लास की एक प्रमुख संपत्ति (ies) होगी जो इंगित करेगी कि यह एक मौजूदा ऑर्डर है या नहीं।

3. मैं डीटीओ के साथ सब कुछ प्रत्यय करूँगा, क्योंकि बहुत सारे डीटीओ वर्ग नाम डोमेन कक्षाओं के समान हैं, वे भ्रमित हो जाते हैं क्योंकि वे एक ही विधि में एक साथ मौजूद होंगे। तो फिर तुम DataContract (नाम = "आदेश", नाम स्थान के साथ अपने DTOs को सजाने कर सकते हैं = "HTP: // yourdomain/.."।।] यह अपनी खुद की पसंद के अनुसार जिस तरह से वे बाहर की दुनिया के संपर्क में आएंगे

मैं एक ही सामान्य प्रोजेक्ट में उपयोग कर रहा हूं, जो सामान्य डोमेन आर्किटेक्चर का उपयोग करता है, मैं आम तौर पर डोमेन पर डीटीओ को मैप करने के लिए ऑटोमैपर का उपयोग करता हूं। यह मेरे लिए बहुत अच्छा काम करता है!