2010-04-21 26 views
48

मुझे पता है कि यह शायद एक पुराना सवाल है, लेकिन बेहतर अभ्यास क्या है? अपने आवेदन की सभी परतों में एक डोमेन मॉडल ऑब्जेक्ट का उपयोग करना, और जेएसपी पर सीधे बाध्यकारी मान भी (मैं जेएसएफ का उपयोग कर रहा हूं)। या डीएओ या सेवा परत में एक डोमेन मॉडल ऑब्जेक्ट को डीटीओ में परिवर्तित करें और प्रस्तुति परत में हल्के डीटीओ भेजें।डीटीओ या डोमेन मॉडल ऑब्जेक्ट?

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

मैं नोट करना चाहिए कि मेरे ऐप हाइबरनेट मॉडल वस्तुओं का उपयोग करता है और अपने स्वयं के कस्टम बनाया मॉडल वस्तुओं (किसी भी डीबी सत्र, हमेशा अलग करने के लिए बाध्य नहीं अर्थ) का उपयोग करता है। क्या उपरोक्त परिदृश्यों में से कोई भी सख्त मॉडल ऑब्जेक्ट पैटर्न के लिए अधिक फायदेमंद है? आलसी प्रारंभिक अपवाद जैसे चीजों के संबंध में हाइबरनेट का उपयोग करना एक विशाल पिटा रहा है।

मैं चर्चा को आगे बढ़ाने की उम्मीद में इस सवाल (यकीन नहीं अगर मैं यह सही कर रहा हूँ) संपादन कर रहा हूँ:

समस्या मैं मॉडल वस्तुओं के साथ है कि वे सब पर लचीला नहीं हैं। नीचे दी गई एक टिप्पणी में कहा गया है कि एप्लिकेशन को डिज़ाइन किया जाना चाहिए ताकि मॉडल ऑब्जेक्ट्स को सभी परतों में उपयोग किया जा सके। क्यूं कर? यदि कोई उपयोगकर्ता हास्यास्पद कार्यक्षमता का एक टुकड़ा चाहता है, तो क्या मुझे उन्हें बताना होगा, 'ठीक है कि मॉडल ऑब्जेक्ट्स के साथ काम नहीं करेगा'?

सादा और सरल जब मॉडल वस्तुओं से काम नहीं चलेगा, वहाँ अभी समय है। आपके पास हो सकता है:

public class Teacher { 
    List<Student> students; 
    [tons of other Teacher-related fields] 
} 
public class Student { 
    double gpa; 
    [tons of other Student-related fields] 
} 

लेकिन शायद आपको वह सारी जानकारी की आवश्यकता नहीं है। आपको सिर्फ शिक्षक के अंतिम नाम की आवश्यकता है, इस साल वे जो छात्र पढ़ाते हैं, और संयुक्त छात्रों के लिए औसत जीपीए की संख्या। आप उस मामले में क्या करेंगे? पूर्ण शिक्षक की जानकारी और छात्र संबंधों को पुनः प्राप्त करें और फिर आपके कोड को छात्रों की सूची पर गिनती मिलती है, फिर अंदर सभी जीपीए की कुल औसत गणना करता है? ऐसा लगता है कि 'स्ट्रिंग अंतिम नाम', 'int numStudents', और 'डबल संयुक्त जीपीए' के ​​साथ एक डीटीओ बनाने की तुलना में अधिक प्रयास की तरह लगता है;

ऐसा लगता है कि मेरे मन इन पर किया गया है लग सकता है, लेकिन मैं अभी तक एक आवेदन जहां मॉडल वस्तुओं पूरी तरह से हर मामले में सफाई से इस्तेमाल किया जा सकता में काम करना है। साधारण वास्तविक दुनिया के अनुप्रयोगों के साथ नियमित वास्तविक दुनिया की मांग सिर्फ इस तरह से काम नहीं करती है।

उत्तर

30

में एक स्पष्ट कटौती जवाब यह वास्तव में आपके आवेदन की जटिलता पर निर्भर करता है नहीं कर रहा हूँ। दृश्य परत में डोमेन वस्तुओं मिश्रण दो संभावित प्रभाव पड़ता है:

  1. आप अपने डोमेन वस्तु को संशोधित करने चीजें आप दृश्य परत में की जरूरत है
  2. आपका परत देखें एक की वजह से अतिरिक्त जटिलता शामिल होंगे समायोजित करने के लिए परीक्षा हो जाएगा आपके डोमेन ऑब्जेक्ट्स की पेशकश के बीच मेल नहीं खाएं और आपके दृश्य को वास्तव में क्या चाहिए। हो सकता है कि आप इस जटिलता को पाने में सक्षम न हों लेकिन शायद यह दृश्य परत में नहीं है।

यदि आपकी डोमेन ऑब्जेक्ट सरल हैं और आपके विचार कम हैं, तो डीटीओ छोड़ना सबसे आसान बात हो सकती है।

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

-4

डीटीओ व्यापक रूप से एक विरोधी पैटर्न आजकल माना जाता है, और सलाह "उन्हें हर कीमत पर से बचने के" आम तौर पर है।

हाइबरनेट की तरह एक ORM ढांचे के मुख्य लाभ में से एक यह है कि आप सभी स्तरों पर डोमेन ऑब्जेक्ट का उपयोग कर सकते हैं और वास्तव में DTOs की आवश्यकता नहीं है। बेशक, यह है कि आपको उन रिश्तों पर कुछ समय के लिए समर्पित करना है: आलसी लाने के लिए, कब उत्सुकता का उपयोग करना है, आदि

+0

हाँ मैं समझता हूं। यह वास्तव में ऐसा लगता है जैसे कभी-कभी यह आवश्यक जटिलता को जोड़ता है। अगर मेरे पास एक ऑब्जेक्ट है जो कहता है कि एक शिक्षक का प्रतिनिधित्व करता है और कई बार मुझे केवल हेडर जानकारी (नाम, पता) की आवश्यकता होती है, तो मुझे आधे-आबादी वाले डोमेन ऑब्जेक्ट को फ्रंट-एंड पर भेजना होगा। यह सिर्फ भ्रामक है और मेरे लिए सही नहीं लगता है। – sma

+4

@ smayers81 - आप केवल अपने डोमेन ऑब्जेक्ट्स को आधे रास्ते क्यों पॉप्युलेट कर रहे हैं? यह एक अनावश्यक अनुकूलन की तरह लगता है (यदि आपने प्रोफाइल की समस्या नहीं ली है या अन्यथा समस्या की खोज की है)। यह आपकी समस्या की जड़ की तरह लगता है - आपके डोमेन ऑब्जेक्ट्स जैसे डीटीओ का इलाज करना। क्यों न केवल अपने पूर्ण हाइड्रेटेड डोमेन ऑब्जेक्ट्स को फ्रंट एंड पर दबाएं? यदि आपको पता चलता है कि आपके पास प्रदर्शन समस्या है, तो आपके पास डीटीओ के लिए एक मामला है (या कस्टम ऑब्जेक्ट्स को पूरी तरह से बाईपास करने के लिए और सीधे आपके फ्रेमवर्क द्वारा प्रदान किए जाने वाले रिकॉर्डसेट के साथ सीधे काम करने के लिए)। –

+0

क्योंकि मैंने हमेशा महसूस किया है, अगर तार की जरूरत नहीं है तो तार पर उस डेटा को क्यों भेज दें। मुझे लगता है कि हाइबरनेट के आलसी लाने के विचार के पीछे यह पूरी प्रेरणा थी (मैं वहां गलत हो सकता था) – sma

7

डोमेन ऑब्जेक्ट्स के लिए एक और वोट। जहां तक ​​डोमेन संचालित डिजाइन का संबंध है, डोमेन मॉडल राजा है और जहां संभव हो वहां उपयोग किया जाना चाहिए। आवेदन को ऐसे तरीके से डिजाइन किया जाना चाहिए जहां अधिकांश परतें (बार इंफ्रास्ट्रक्चर परत) डोमेन ऑब्जेक्ट्स का उपयोग कर सकें।

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

+3

दृश्य से हटा दिया जाना चाहिए मैंने सोचा था कि सत्र के लिए क्रमबद्धता की आवश्यकता थी क्लस्टर वातावरण में राज्य प्रबंधन? यहां तक ​​कि हमारे पास मॉडल ऑब्जेक्ट्स भी हैं (हाइबरनेट और कस्टम, डिटेक्टेड वाले) सीरियलज़ेबल हैं। – sma

+2

मुझे नहीं लगता कि वह उस धारावाहिकता का जिक्र कर रहा था जिसके बारे में आप बात कर रहे हैं (ए-ला सीरियलज़ेबल)।मुझे लगता है कि उनका मतलब एक्सएमएल, जेएसओएन, एएमएफ (फ्लेक्स), सीएसवी इत्यादि जैसी चीजों को क्रमबद्ध करना था। – Aquarelle

2

परिदृश्य जब डोमेन वस्तु भेजे जाने के लिए समस्याग्रस्त हैं:

  1. आप एकत्रित जानकारी या (उदाहरण के फ्लेक्स/GWT में) यूआई परत के लिए भेजा 'गणना फ़ील्ड' के अन्य प्रकार की आवश्यकता हो सकती है और नहीं करना चाहते गड़बड़ करने के लिए डोमेन वस्तु
  2. आप चक्रीय वस्तु ग्राफ serializing के लिए एक की जरूरत का सामना कर सकते हैं (अपने उदाहरण में, यदि छात्र सूची संबंध था), कुछ प्रोटोकॉल कि
  3. हाइबरनेट LazyInitializationException साथ कोई समस्या है जब के लिए (BlazeDS ढांचे serializers के साथ काम फ्लेक्स/जीडब्ल्यूटी सीरिएलाइज़र)

मुझे यकीन है कि यह उन cirumcstances

7

मुझे लगता है कि डीटीओ आमतौर पर एक विरोधी पैटर्न नहीं है। उनमें से बहुत से लोग और सिस्टम हैं और आपको जो लाभ मिलता है वह निर्णायक दृश्य परत है जिसे डोमेन मॉडल से स्वतंत्र रूप से डिज़ाइन और मॉड्यूलर किया जा सकता है। हालांकि मैं मानता हूं कि आपको डोमेन ऑब्जेक्ट्स का उपयोग करना चाहिए जहां संभव हो वहां ऐसे परिदृश्य हैं जहां आप सीधे डोमेन मॉडल पर दृश्य परत को बांधते समय समस्याएं प्राप्त कर सकते हैं।

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

1

मेरी राय में, प्रत्येक परत में डोमेन मॉडल ऑब्जेक्ट्स का उपयोग करने में कोई समस्या नहीं है। आपने कहा कि आपको सभी जानकारी की आवश्यकता नहीं है। जब आप अपने जेएसपी में हों, तो केवल उस डेटा का उपयोग करें जो आपको चाहिए। कोई भी आपको हर संपत्ति लाने के लिए मजबूर नहीं कर रहा है। आपने यह भी कहा कि आपको जीपीए, छात्रों के # आदि प्राप्त करने के लिए ऑब्जेक्ट की संपत्तियों से संबंधित गणना करने की आवश्यकता है। आपके पास 3 विकल्प हैं: अपने डोमेन मॉडल ऑब्जेक्ट में सिंथेटिक गुण बनाएं जो आपके लिए सही डेटा लौटाए, अच्छा लगा और साफ; नियंत्रक या सेवा परत में गणना करें, और उपयुक्त गेटर्स के माध्यम से उन्हें बेनकाब करें; या इसे अपने जेएसपी के अंदर सब कुछ संभाल लें। आपको किसी भी डेटा को पुनर्प्राप्त/संकलित/wrangle करने की आवश्यकता है, तो डीटीओ के साथ और अधिक जटिलता क्यों जोड़ें।

इसके अतिरिक्त, प्रत्येक डीटीओ के साथ, आप एक बना रहे हैं।) एक अतिरिक्त कक्षा जिसे अब आप बनाए रखना है, और बी।) कुछ कक्षा में कहीं भी कम से कम 1 अतिरिक्त विधि पर जो डीटीओ (डीएओ, फैक्ट्री विधि) बनाता है और पॉप्युलेट करता है , आदि।)। अधिक रखरखाव = 6 महीने बाद दुखी डेवलपर।

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

-1

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

दूसरी ओर मुझे लगता है कि बहुत कम चीजें हैं जिन्हें आपको आम तौर पर नहीं करना चाहिए। जो लोग सभी डीटीओ कहते हैं वे बुरे हैं गलत हैं - यह हमेशा उपयोग के मामले पर निर्भर करता है! क्या वे वास्तव में उचित हैं?

और आखिरकार, मुझे व्यक्तिगत रूप से विश्वास है कि डोमेन ऑब्जेक्ट को दृश्य में ही जाना चाहिए। कल्पना करें कि विकेट एकीकरण कैसा है। लेकिन उदाहरण के लिए स्प्रिंग एमवीसी लें - डोमेन संभवतः आवेदन परत में रहेगा ...

0

कक्षा का व्यवहार, या इसकी आंतरिक विधियों को उनके व्यवहार से संबंधित परतों के संपर्क में नहीं आना चाहिए। डेटा स्थानांतरित करें, व्यवहार नहीं। डोमेन के भीतर डोमेन ऑब्जेक्ट्स का प्रयोग करें। वेब एक नियंत्रित डोमेन नहीं है, और यूआई डेवलपर्स को डोमेन व्यवहार, सिर्फ डेटा से संबंधित नहीं होना चाहिए।

डोमेन को डोमेन के स्वास्थ्य से संबंधित किसी व्यक्ति द्वारा संशोधन से संरक्षित किया जाना चाहिए, और संशोधित किया जाना चाहिए।

लीकिंग व्यवहार सबसे अच्छी आदत नहीं है।

यदि यह एक छोटी परियोजना है, तो इसे सही प्रधानाध्यापकों के साथ भी बनाया गया है। इस तरह हम हमेशा ध्यान में रखते हैं कि हम जो करते हैं हम करते हैं, न कि कैसे।

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