जेपीए इकाइयां और/बनाम डीटीओ

Question

डीटीओ का उपयोग कब करना है और इन मामलों में इकाई का उपयोग कब करना है, यह तय करने में सामान्य विचार क्या है?

1. यूआई/सर्वर साइड जावा सेवाओं को बुला रहा है। क्या इसे संस्थाएं या डीटीओ भेजना/भेजना चाहिए?
2. सेवाएं सेवा कॉल करने वाली वेब सेवा। क्या सेवाओं को संस्थाओं या डीटीओ स्वीकार करना चाहिए?

मैं कोड है कि संस्थाओं के आसपास पारित पढ़ना:

1. सरल आसपास पारित करने के लिए, DTOs को मैप करने की कोई जरूरत
2. न अतिरिक्त कक्षाओं अन्य संस्थाओं के लिए
3. संबंधों पहले ही निर्धारित कर की जरूरत है है, तो न एक डीटीओ में संबंधित DTOs गठबंधन की जरूरत
4. सिर्फ POJOs

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

डीटीओ के विपक्ष मैं है के बारे में सोच सकते हैं स्वीकार करता है को देखते बिंदु से

1. पिछड़े संगत:
   तो यहाँ

   DTOs का उपयोग कर के पेशेवरों की सूची दी गई है:

   1. डीटीओ वर्गों और मानचित्रण (डोजर शायद का उपयोग)
   2. प्रोग्रामर निर्धारित करने की ज होगा जब डीटीओ और इकाई का उपयोग करने का विश्लेषण करने के एवेन्यू, मैं हर तरीकों के लिए डीटीओ खरा उतरने का आशय एक मेस DTOs के लिए संस्थाओं के रूपांतरण के
   3. भूमि के ऊपर और इसके विपरीत
   4. im अभी भी पर कैसे करने के लिए एक-से-अनेक संबंध के बारे में अनिश्चित है उन्हें मानचित्रित करें। जेपीए में हम आलसी शुरुआत कर सकते हैं, लेकिन डीटीओ में गुजरने पर, क्या मुझे इसे शुरू करना चाहिए या नहीं। संक्षेप में, डीटीओ में आलसी प्रारंभिक प्रॉक्सी नहीं हो सकते हैं, केवल मूल्य होते हैं।

   आप विचारों को साझा करें ..

   धन्यवाद!

   एक डीटीओ के रूप में इकाई वर्ग के पुन: उपयोग गन्दा लगता है:

   यहाँ अलग-अलग स्थानों

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

   pro entity:

   बिल्कुल नहीं !!!

   जेपीए इकाइयों को डेटाबेस, पर मैप किया गया है लेकिन वे डेटाबेस से 'बंधे' नहीं हैं। यदि डेटाबेस बदलता है, तो आप मैपिंग बदलते हैं, ऑब्जेक्ट्स नहीं। ऑब्जेक्ट्स वही रहते हैं। यह पूरा बिंदु है!

Answer 1

मैं निम्नलिखित कारणों के लिए डीटीओ विकल्प के लिए जाना होगा:

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

Answer 2

प्रो डीटीओ: 1. यूआई ज्यादातर बार कुछ गुणों की आवश्यकता होती है जो केवल यूआई राज्य को दर्शाते तर्कों को पारित करने के लिए होती हैं। इसलिए राज्य को जारी रखने की आवश्यकता नहीं है, इसलिए संस्थाओं पर उपयोग करने की आवश्यकता नहीं है।
2. व्यापार तर्क इकाइयों के लिए या सहायक वर्गों के भीतर होना चाहिए। आपको इसे UI/प्रेजेंटेशन लेयर या क्लाइंट कॉलिंग के साथ साझा नहीं करना चाहिए।
3. इकाइयों में परिवर्तन कभी-कभी डीटीओ में बदलाव की आवश्यकता नहीं होती है और इसके विपरीत।
4. यूआई सेवाओं में डीटीओ पर सिस्टम स्तर सत्यापन करने के लिए आसान है, इसलिए जब इसे नहीं करना चाहिए तो व्यापार सेवाओं को कॉल रोकना।
5. यूआई पक्ष से आने वाले डेटा से भरे इकाई के बजाय यूआई पक्ष डीटीओ प्राप्त कर रहा है, तो आप अन्य सत्यापन फ्रेमवर्क को स्वतंत्र रूप से कार्यान्वित/उपयोग कर सकते हैं।
6. यूआई/प्रस्तुति परत कम से कम युग्मित है।

यहां नमूने के प्रवाह जब DTOs उपयोग किया जाता है:
यूआई -> MVC -> सिस्टम सत्यापन यूआई सेवाओं का उपयोग करना -> व्यवसाय के प्रतिनिधि -> व्यापार सेवाएँ -> लागू हैं।