क्लास डुप्लीकेशन पैटर्न?


11

मैं वर्तमान में अपने वर्तमान प्रोजेक्ट पर एकल डेवलपर के रूप में काम कर रहा हूं। मुझे एक अन्य डेवलपर से प्रोजेक्ट विरासत में मिला है, जिसने कंपनी छोड़ दी है। यह C # में एक मॉडल-व्यू-कंट्रोलर स्टाइल वेब एप्लिकेशन है। यह ऑब्जेक्ट रिलेशनल मैपिंग के लिए एंटिटी फ्रेमवर्क का उपयोग करता है। और डोमेन मॉडल में प्रकारों के लिए कक्षाओं के दो अलग-अलग सेट हैं। एक सेट का उपयोग ORM के साथ बातचीत के लिए किया जाता है और दूसरे का उपयोग MVC सिस्टम में मॉडल के रूप में किया जाता है। उदाहरण के लिए, निम्न दो वर्ग हो सकते हैं:

public class Order{
    int ID{get;set;}
    String Customer{get;set;}
    DateTime DeliveryDate{get;set;}
    String Description{get;set;}
}

तथा

public class OrderModel{
    String Customer{get;set;}
    DateTime DeliveryDate{get;set;}
    String Description{get;set;}
    public OrderModel( Order from){
        this.Customer= from.Customer;
        // copy all the properties over individually
    }
    public Order ToOrder(){
        Order result =new Order();
        result.Customer = this.Customer;
        // copy all the properties over individually
    }

}

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

अपडेट करें

यहाँ कुछ उत्तर मुझे यह एहसास करा रहे हैं कि परियोजना के बारे में मेरा प्रारंभिक विवरण कुछ महत्वपूर्ण विवरणों की कमी था। कक्षाओं का एक तीसरा समूह भी है जो परियोजना में मौजूद है: पृष्ठ मॉडल कक्षाएं। वे वास्तव में पृष्ठ का समर्थन करने वाले मॉडल के रूप में उपयोग किए जा रहे हैं। उनमें ऐसी जानकारी भी होती है जो UI के लिए विशिष्ट होती है, और इसे डेटाबेस में एक आदेश के साथ संग्रहीत नहीं किया जाएगा। एक उदाहरण पृष्ठ मॉडल वर्ग हो सकता है:

public class EditOrderPagelModel
{
    public OrderModel Order{get;set;}
    public DateTime EarliestDeliveryDate{get;set;}
    public DateTime LatestAllowedDeliveryDate{get;set;}
}

मैं पूरी तरह से इस तीसरे समूह की उपयोगिता को यहां अलग-अलग देखता हूं, और इसे किसी और चीज के साथ विलय करने की कोई योजना नहीं है (हालांकि मैं नाम बदल सकता हूं)।

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

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


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

अपने अपडेट के बारे में: जो पर्याप्त लाभ के लिए बहुत अधिक अप्रत्यक्ष लगता है।
रॉबर्ट हार्वे

@RobertHarvey क्या आप बहुत अधिक अप्रत्यक्ष होने का उल्लेख कर रहे हैं?
रॉबर्ट रिकेट्स

1
ऑर्डरमॉडल। OrderViewModel (जो आपके संभवतः EditOrderPageModel के रूप में संदर्भित कर रहा है) पर्याप्त अप्रत्यक्ष है; नीचे मेरा जवाब देखें।
रॉबर्ट हार्वे

@ रोबर्टहवे इस सवाल के जवाब की तरह लगता है कि मैं वास्तव में पूछने की कोशिश कर रहा था
रॉबर्ट रिकेट्स

जवाबों:


16

तो क्या मुझे यहाँ कुछ महत्वपूर्ण याद आ रहा है?

हाँ

जबकि ये एक ही चीज़ की तरह दिखते हैं, और डोमेन में एक ही चीज़ का प्रतिनिधित्व करते हैं, वे समान (OOP) ऑब्जेक्ट नहीं हैं।

एक Orderकोड के डेटा भंडारण भाग द्वारा ज्ञात है। अन्य OrderUI के रूप में जाना जाता है। हालांकि यह एक सुखद संयोग है कि इन वर्गों में समान गुण हैं, उन्हें इसकी गारंटी नहीं है।

या इसे दूसरे दृष्टिकोण से देखने के लिए, एकल जिम्मेदारी सिद्धांत पर विचार करें। यहां मुख्य प्रेरक यह है कि "एक वर्ग को बदलने का एक कारण है"। विशेष रूप से जब ORM और / या UI फ्रेमवर्क जैसे व्यापक ढांचे के साथ काम करते हैं, तो आपकी वस्तुओं को अच्छी तरह से अलग-थलग करने की आवश्यकता होती है क्योंकि फ्रेमवर्क में परिवर्तन अक्सर आपकी संस्थाओं को बदलने का कारण होगा।

अपनी संस्थाओं को दोनों ढाँचों में बांधकर , आप इसे इतना बदतर बना रहे हैं।


7

व्यू मॉडल का उद्देश्य दो तरीकों से डिकोडिंग प्रदान करना है: आकार में डेटा प्रदान करके जिसे व्यू की आवश्यकता है (मॉडल से स्वतंत्र), और (विशेष रूप से एमवीवीएम में) व्यू से कुछ या सभी व्यू लॉजिक को पीछे धकेल कर मॉडल को देखने के लिए।

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

दूसरी ओर एक दृश्य मॉडल, Nameग्राहक के लिए अधिक रूचि वाला हो सकता है , न कि आईडी का। जब तक ग्राहक मॉडल में अपडेट नहीं किया जाता है, तब तक उसे आईडी की कोई आवश्यकता नहीं है।

इसके अलावा, देखें मॉडल, और आमतौर पर करता है, एक अलग आकार ले सकता है (जब तक कि यह शुद्ध सीआरयूडी नहीं है )। एक चालान दृश्य मॉडल ऑब्जेक्ट में ग्राहक का नाम, पते और लाइन आइटम हो सकते हैं, लेकिन मॉडल में ग्राहक और विवरण शामिल हैं।

दूसरे शब्दों में, चालान आम तौर पर उसी तरीके से संग्रहीत नहीं किए जाते हैं जैसे वे प्रदर्शित होते हैं।


3

कुछ मामलों में आप सही हैं: वे दोनों एक ही डोमेनोबिज के लिए संदर्भित करते हैं, जिसे कहा जाता है order। लेकिन जहां तक ​​आप गलत हैं, यह एक अलग प्रतिनिधित्व से वास्तविक दोहराव नहीं है - विभिन्न उद्देश्यों से उत्पन्न। यदि आप अपने आदेश को जारी रखना चाहते हैं, तो आप उदाहरण के लिए प्रत्येक स्तंभ तक पहुँच चाहते हैं। लेकिन आप इसे बाहर तक लीक नहीं करना चाहते हैं। तार के माध्यम से संपूर्ण संस्थाओं को आगे बढ़ाने के अलावा वह नहीं है जो आप वास्तव में चाहते हैं। मुझे उन मामलों का पता है, जहां एमबी का एक संग्रह ordersक्लाइंट को भेज दिया गया था जहां कुछ केबी पर्याप्त होगा।

एक लंबी कहानी को छोटा करने के लिए - यहाँ मुख्य कारण हैं जो आप करना चाहते हैं:

1) एनकैप्सुलेशन - आपके आवेदन की जानकारी छिपाना

2) छोटे मॉडल तेजी से प्रसारित और प्रसारित करने में आसान होते हैं

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

4) कभी-कभी यह अलग - अलग क्वेरी के लिए अलग - अलग मूल्य-वस्तुओं के लिए समझ में आता है । मुझे नहीं पता कि यह C # में कैसे है, लेकिन जावा में परिणाम एकत्र करने के लिए POJO का उपयोग करना संभव है । अगर मुझे एक एकल की आवश्यकता है तो मैं ऑर्डर -इंटिटी का orderउपयोग करता हूं, लेकिन अगर मुझे केवल डेटा पर मात्राओं से भरे कुछ स्तंभों की आवश्यकता है, तो छोटी वस्तुओं का उपयोग करना अधिक कुशल है।


जिस तरह से इकाई ढांचे को संरचित किया जाता है, संस्थाएं पुराने पुराने सी # ऑब्जेक्ट हैं, इसलिए उन्हें तार पर भेजना वास्तव में बहुत समस्या नहीं है। मुझे कुछ परिस्थितियों में आदेश की सामग्री का सिर्फ एक हिस्सा भेजने में सक्षम होने की उपयोगिता दिखाई देती है।
रॉबर्ट रॉकेट्स

एक या एक गुच्छा समस्या नहीं है जैसा मैंने कहा था। लेकिन ऐसे मामले हैं, जहां आपके पास एमबी का डेटा है, जो आपके लोडटाइम को धीमा कर देता है। मोबाइल लोड समय के बारे में सोचो
थॉमस जंक

0

(अस्वीकरण: मैंने केवल इसे इस तरह से उपयोग करते हुए देखा था। ऐसा करने के वास्तविक उद्देश्य को मैंने गलत समझा हो सकता है। इस उत्तर को संदेह से समझें।)

यहाँ एक और गुम सा है: Orderऔर के बीच का रूपांतरण OrderModel

Orderवर्ग अपने ORM से जुड़ा हुआ है, जबकि OrderModelअपने दृश्य मॉडल के डिजाइन से जुड़ा हुआ है।

आमतौर पर, दो तरीकों को "एक जादुई तरीके से" प्रदान किया जाएगा (कभी-कभी डीआई, आईओसी, एमवीवीएम, या अभी तक एक और बात)। इसके बजाय, इन दो रूपांतरण विधियों को लागू करने के बजाय OrderModel, वे इन चीजों के अंतर-रूपांतरण के लिए समर्पित एक वर्ग के होंगे; उस वर्ग को किसी तरह फ्रेमवर्क के साथ पंजीकृत किया जाएगा ताकि फ्रेमवर्क आसानी से उसे देख सके।

public class OrderModel {
    ...
    public OrderModel(Order from) { ... }
    public Order ToOrder() { ... }
}

ऐसा करने के लिए कारण जब भी वहाँ से एक पार है OrderModelकरने के लिए Orderया इसके विपरीत, आप जानते हैं कि कुछ डेटा से लोड किया गया होगा या ORM में बचा लिया।


अगर मैं दोनों को अपने आस-पास रख रहा हूं, तो मैं निश्चित रूप से उन्हें स्थापित करना चाहूंगा कि रूपांतरण अधिक स्वचालित हो
रॉबर्ट रिकेट्स

@RobertRicketts जिस चीज़ को मैंने देखा वह इस प्रकार है: IMvxValueConverter । हालाँकि मुझे इसका उद्देश्य गलत लग सकता है।
rwong
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.