डीटीओ नामकरण सम्मेलन, मॉडलिंग और विरासत

Question

हम AngularJS, C#, ASP.Net वेब API और Fluent NHibernate का उपयोग करके एक वेब ऐप बना रहे हैं। हमने प्रस्तुति परत (कोणीय दृश्य) में डेटा स्थानांतरित करने के लिए डीटीओ का उपयोग करने का निर्णय लिया है। मुझे डीटीओ की सामान्य संरचना और नामकरण के बारे में कुछ संदेह थे। मेरे परिदृश्य को चित्रित करने के लिए यहां एक उदाहरण दिया गया है। चलें कहते हैं कि मैं एक डोमेन इकाई बुलाया ग्राहक जो लगता है कि है:

1) बस क्रमांक और नाम :

public class Customer 
    { 
     public virtual int Id { get; set; } 
     public virtual string Name { get; set; } 
     public virtual Address Address { get; set; } 
     public virtual ICollection<Account> Accounts { get; set; } 
    } 

अब, मेरे विचार में/प्रस्तुति परत मैं की तरह ग्राहक के विभिन्न जायके को पुनः प्राप्त करने की जरूरत है 2) क्रमांक, नाम और पता 3) आईडी, नाम, पता और

मैं यह पूरा करने के DTOs का एक सेट बनाया है लेखा:

public class CustomerEntry 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
} 

public class CustomerWithAddress : CustomerEntry 
{ 
    public AddressDetails Address { get; set; } 
} 

public class CustomerWithAddressAndAccounts : CustomerWithAddress 
{ 
    public ICollection<AccountDetails> Accounts { get; set; } 
} 

पता विवरण और खाता विवरण डीटीओ हैं जिनके पास उनके संबंधित डोमेन इकाइयों के सभी गुण हैं।

यह क्वेरीिंग और डेटा पुनर्प्राप्ति के लिए ठीक काम करता है; सवाल यह है कि मैं आवेषण और अद्यतन के लिए क्या उपयोग करता हूं। एक नए ग्राहक रिकॉर्ड के निर्माण के दौरान, नाम और पता अनिवार्य हैं और खाते वैकल्पिक हैं .. इसलिए दूसरे शब्दों में मुझे सभी ग्राहक गुणों के साथ एक वस्तु की आवश्यकता है। इसलिए भ्रम:

1) मैं सम्मिलित करने और अपडेट के लिए क्या उपयोग करूं? ग्राहक WithAddressAndAccounts डीटीओ में सबकुछ है लेकिन इसका नाम डालने/अपडेट के लिए उपयोग करने के लिए थोड़ा अजीब लगता है।

2) क्या मैं एक और डीटीओ बना सकता हूं .. यदि मैं करता हूं, तो क्या यह डुप्लीकेट नहीं होगा क्योंकि नया डीटीओ बिल्कुल ग्राहक की तरह होगा। एड्रेस और अकाउंट्स?

3) आखिरी लेकिन कम से कम नहीं, क्या ऊपर वर्णित डीटीओ विरासत स्ट्रक्चर आवश्यकता के लिए एक अच्छा फिट लगता है? क्या इसका मॉडल करने के कोई अन्य तरीके हैं?

मैं इस विषय पर अन्य पोस्टों के माध्यम से चला गया हूं लेकिन बहुत अधिक रास्ता नहीं बना सका। एक चीज जिसे मैंने पिकअप किया था, वर्ग नामों में प्रत्यय "डीटीओ" का उपयोग करने से बचाना था। मुझे लगता है कि यह थोड़ा अनावश्यक लगता है।

में आपके विचार जानना

धन्यवाद

Answer 1

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

इसके अलावा, एक सार DTOBase आधार वर्ग या इंटरफ़ेस जोड़ें; और बच्चे डीटीओ में शामिल होने के लिए प्रत्येक पते, खाते और अन्य गुणों के लिए ऐसी गहरी विरासत विरासत का उपयोग न करें।

[Serializable] 
public class CustomerEntryDTO : DTOBase, IAddressDetails, IAccountDetails 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public AddressDetails Address { get; set; } //Can remain null for some Customers 
    public ICollection<AccountDetails> Accounts { get; set; } //Can remain null for some Customemer 
} 

इसके अलावा, अपने DTOs प्रक्रिया सीमाओं के पार पारित होने के लिए serializable होना चाहिए: बल्कि, एक ही CustomerEntryDTO कक्षा में इन गुणों (यदि संभव हो) नीचे के रूप में शामिल हैं।

डीटीओ तर्ज पर अधिक जानकारी के लिए

, लेख नीचे देखें:

Data Transfer Object

MSDN

संपादित करें: मामले में आप तार पर कुछ गुण भेजने के लिए नहीं करना चाहते हैं (मुझे पता है कि आपको उस सशर्त रूप से आवश्यकता होगी, इसलिए इस पर और अधिक जानने की आवश्यकता होगी), आप उन्हेंजैसे गुणों का उपयोग करके सीरियलाइजेशन तंत्र से बाहर कर सकते हैं(लेकिन यह केवल फ़ील्ड पर काम करता है और गुण नहीं, गुणों के साथ उपयोग करने के लिए वर्कअराउंड आलेख देखें: NonSerialized on property)। आप अपनी खुद की कस्टम विशेषता भी बना सकते हैं जैसे ExcludeFromSerializationAttribute और इसे उन गुणों पर लागू करें जिन्हें आप कुछ नियमों/शर्तों के आधार पर तार पर हर बार भेजना नहीं चाहते हैं। यह भी देखें:Conditional xml serialization

संपादित करें 2: एक CustomerEntryDTO कक्षा में विभिन्न गुणों अलग करने के लिए इंटरफेस का प्रयोग करें। Google या MSDN पर इंटरफ़ेस पृथक्करण सिद्धांत देखें। मैं बाद में नमूना स्पष्टीकरण देने की कोशिश करूंगा।

Answer 2

आपके आइटम 1 के रूप में, आवेषण और अपडेट के लिए कमांड पैटर्न का उपयोग करना बेहतर होता है। सीक्यूआरएस के अनुसार, आपको डीटीओ की आवश्यकता नहीं है। के माध्यम से blogs.msdn.com

Answer 3

मैं डालने और अपडेट के लिए क्या प्रयोग करते हैं: इस स्कीमा पर विचार करें?

1. सेवा संचालन आम तौर पर व्यापार कार्य करने के लिए बहुत करीब संबंध में परिभाषित कर रहे हैं। व्यवसाय भाषा "आवेषण" और "अपडेट" के मामले में नहीं बोलती है, न ही सेवाएं करती है।

2. ग्राहक प्रबंधन सेवा में Register ऑपरेशन होने की संभावना है जो ग्राहक का नाम ले सकता है और शायद कुछ अन्य वैकल्पिक पैरामीटर।

मैं एक और डीटीओ बनाना चाहते हैं?

हां, आपको एक और डीटीओ बनाना चाहिए।

कभी कभी सेवा आपरेशन अनुबंध पर्याप्त हो सकता है और एक विशेष ऑपरेशन के लिए एक अलग डीटीओ परिभाषित करने के लिए कोई जरूरत नहीं है:

function Register(UserName as String, Address as Maybe(of String)) as Response 

लेकिन समय यह बेहतर है के लिए ही यहां तक ​​कि एक अलग डीटीओ वर्ग को परिभाषित करने के लिए के सबसे एक एकल सेवा आपरेशन: क्योंकि यह समान फ़ील्ड

class RegisterCommand 
    public UserName as String 
    public Address as Maybe(of String) 
end class 

function Register(Command as RegisterCommand) as Response 

RegisterCommand डीटीओ बहुत CustomerWithAddress डीटीओ के लिए इसी तरह लग सकता है लेकिन वास्तव में इन 2 DTOs बहुत अलग अर्थ है और एक दूसरे के स्थानापन्न नहीं है।

उदाहरण के लिए, CustomerWithAddress में AddressDetails है, जबकि एक साधारण String पता प्रतिनिधित्व ग्राहक को पंजीकृत करने के लिए पर्याप्त हो सकता है।

प्रत्येक सेवा संचालन के लिए एक अलग डीटीओ का उपयोग करने के लिए लिखने में अधिक समय लगता है लेकिन बनाए रखना आसान होता है।