मैं डोमेन/इकाई/डीटीओ ऑब्जेक्ट्स के डुप्लिकेशंस को कैसे कम करूं?

Question

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

मेरा नया संरचना जैसे खर्च की गई थी:

ग्राहक:
Reporting.Silverlight = सिल्वरलाइट अनुप्रयोग। यह मेरे डीटीओ कक्षाओं का संदर्भ देगा।
रिपोर्टिंग.Web = मेरा एसएल ऐप रखता है और लोगों के लिए यह मुख्य प्रवेश बिंदु है।

व्यवसाय:
Reporting.Services = मेरे WCF सेवाओं यहां मौजूद रहती है। मेरा एसएल ऐप सामान करने के लिए इसे कॉल करेगा, और ये सेवाएं डीटीओ कक्षाएं वापस कर देगी।
रिपोर्टिंग.Services.Contracts = डब्ल्यूसीएफ सेवाओं के लिए मेरे इंटरफेस रखता है, और डेटाकंट्रक्ट सजावट के साथ मेरे डीटीओ कक्षाएं रखता है।
Reporting.Domain = धारण मेरे डोमेन वस्तुओं और व्यापार तर्क

डाटा:
Reporting.Data.Contract =
Reporting.Data काम का भंडार & इकाई के लिए मेरे इंटरफेस रखती है = भंडार/यूओडब्ल्यू का कंक्रीट कार्यान्वयन। इकाई फ्रेमवर्क 5 संदर्भ यहां परिभाषित किया गया है।
रिपोर्टिंग। डेटा.मोडल्स = मेरी सभी इकाई वस्तुओं को पकड़ता है ताकि ईएफ 5 एसक्यूएल के साथ अपनी चीज कर सके।

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

[DataContract(Name = "ComputerDTO")] 
public class ComputerDTO 
{ 
    [DataMember(Name = "Hostname")] 
    public string Hostname { get; set; } 

    [DataMember(Name = "ServiceTag")] 
    public string ServiceTag { get; set; } 

    // ... lots more 
} 

मुझे लगता है कि इसके बाद के संस्करण डीटीओ, ठीक है यह रूप में सिर्फ गुण है कि SL ग्राहक को पारित कर दिया हो का एक समूह। मेरे डीटीओ गुणों का विशाल बहुमत आईडी फ़ील्ड को छोड़कर मेरी इकाई वस्तुओं की उचितता 1: 1 पर मानचित्र करता है।

[Table("Inventory_Base")] 
public class ComputerEntity 
{ 
    // primary key 
    [Key] 
    public int AssetID { get; set; } 

    // foreign keys 
    public int? ClientID { get; set; } 

    // these props are fine without custom mapping 
    public string Hostname { get; set; } 
    public string ServiceTag { get; set; } 
    // ... plus a bunch more in addition to my navigation properties 
} 

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

public class Computer 
{ 
    public string Hostname { get; set; } 
    public string ServiceTag { get; set; } 
    // ... lots more, pretty much mirrors the DTO 

    public string Method1(string param1) 
    { 
     // lots of methods and logic go in here 
    } 
} 

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

यदि यह परिभाषित करने में मदद करता है कि मैं क्या बेहतर करने की कोशिश कर रहा हूं, तो मुझे बताएं कि मुझे अपनी रिपोजिटरी/यूनिटफॉवर्क पद्धति शामिल करनी चाहिए जो मैं कर रहा हूं।

Answer 1

3 लगभग समान कक्षाएं होने के कारण संभवतः का सही तरीका नहीं हो सकता है, है ना?

आईएमओ वे "3 लगभग समान वर्ग" नहीं हैं, वे एक ही उद्देश्य की सेवा नहीं करते हैं। वे एक ही डोमेन धारणा के कई पहलू हैं, प्रत्येक एक विशिष्ट परत की जरूरतों के अनुरूप बनाया गया है।

मॉड्यूलरिटी और चिंताओं को अलग करने के लिए भुगतान करने की कीमत है। अधिक बंदरगाह (जैसे Hexagonal Architecture के बंदरगाह & एडाप्टर) आपके पास जितने अधिक पहलुओं की आवश्यकता होगी और आपको जितना अधिक मैपिंग करना होगा।

इस पर एक अच्छा लेख: http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/

([इकाई की रूपरेखा 6.0 के तहत ORM संस्थाओं बनाम डोमेन संस्थाओं] की