स्प्रिंग एमवीसी: क्या सेवा परत ऑपरेशन विशिष्ट डीटीओ वापस करनी चाहिए?

Question

मेरे स्प्रिंग एमवीसी एप्लिकेशन में मैं सेवा परत में डोमेन मॉडल को समाहित करने के लिए प्रस्तुति परत में डीटीओ का उपयोग कर रहा हूं। डीटीओ का इस्तेमाल स्प्रिंग फॉर्म बैकिंग ऑब्जेक्ट्स के रूप में किया जा रहा है।

इसलिए मेरी सेवाओं कुछ इस तरह दिखाई:

userService.storeUser(NewUserRequestDTO req); 

सेवा परत डीटीओ अनुवाद करेगा - डोमेन वस्तु> और काम के बाकी है।

अब मेरी समस्या यह है कि जब मैं एक अद्यतन या डिस्प्ले कहने के लिए सेवा से डीटीओ पुनर्प्राप्त करना चाहता हूं तो मुझे ऐसा करने का बेहतर तरीका नहीं दिख रहा है, फिर लुकअप के लिए कई तरीके हैं जो अलग-अलग लौटते हैं डीटीओ की तरह ...

EditUserRequestDTO userService.loadUserForEdit(int id); 

DisplayUserDTO userService.loadUserForDisplay(int id); 

लेकिन कुछ इस दृष्टिकोण के बारे में सही नहीं लगता है। शायद सेवा को EditUserRequestDTO जैसी चीज़ों को वापस नहीं करना चाहिए और नियंत्रक को समर्पित फॉर्म ऑब्जेक्ट से अनुरोध डीटीओ को इकट्ठा करने के लिए ज़िम्मेदार होना चाहिए और इसके विपरीत।

कारण अलग-अलग डीटीओ का कारण यह है कि DisplayUserDTO को केवल पढ़ने के लिए मजबूर किया जाता है और उपयोगकर्ता के कई गुण भी हैं जो डीबी (जैसे शहर और राज्य) में लुकअप टेबल से इकाइयां हैं, इसलिए DisplayUserDTO के पास होगा गुणों का स्ट्रिंग विवरण जबकि EditUserRequestDTO में आईडी होगी जो फ़ॉर्म में चयनित ड्रॉप डाउन सूचियों को वापस लाएगी।

आपको क्या लगता है?

धन्यवाद

Answer 1

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

---

पहला संपादन: नीचे टिप्पणी का उत्तर दें। , आदि संपादित करें, दृश्य बनाते हैं,

आपने कहा कि आप किसी मौजूदा ऑब्जेक्ट और नकल ले जा रहे हैं:

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

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

---

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

Answer 2

आपको डीटीओ का उपयोग करना चाहिए और एमवीसी परत में कभी भी ओआरएम नहीं करना चाहिए! इस पर पहले से पूछे जाने वाले बहुत से अच्छे प्रश्न हैं, जैसे कि निम्नलिखित: Why should I isolate my domain entities from my presentation layer?

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