2009-08-27 14 views
5

मैं डोमेन संचालित डिज़ाइन की अपनी वर्तमान समझ का उपयोग करके एक नया एप्लिकेशन बना रहा हूं। अब तक मेरे पास मेरे डोमेन में इकाइयों का प्रतिनिधित्व करने वाले वर्गों का एक समूह है और डेटाबेस से पुनर्प्राप्त/जारी रखने के लिए एक संग्रह है।डोमेन संचालित डिज़ाइन: जटिल डेटा की सूची कैसे प्राप्त करें

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

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

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

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

उत्तर

2

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

समस्या यह है कि अभी मेरे पास मेरे डोमेन इकाइयों के साथ इस संपूर्ण डेटा सेट का प्रतिनिधित्व करने का कोई तरीका नहीं है।

अजीब डिजाइन घर्षण जो आप यहां महसूस कर रहे हैं वह एक अच्छी बात है। यह एक सुराग है कि चीजें एक साथ फिट नहीं हैं।

+0

ठीक है, अब मैं सेवाओं पर पढ़ रहा हूं। जब आप कहते हैं कि सेवा डेटा को एक दृश्य के रूप में पेश करेगी, तो दृश्य क्या है? क्या यह एक वर्ग है जिसे इस उद्देश्य के लिए परिभाषित किया गया है? क्या यह डोमेन इकाइयों से बना है? –

+1

मैं एमवीसी भावना में दृश्य का उपयोग कर रहा हूं - यानी, जिसका काम आपको चीजों को दिखाने के लिए है। वास्तविक प्रासंगिक डेटा सेवा द्वारा एकत्रित किया जाएगा, जिसे दृश्य तब सौंप दिया जाता है और प्रदर्शित करने के लिए कहा जाता है (आपके मामले में, यह आपके द्वारा उल्लेख की गई "डेटा की सूची" है)।एक सेवा अलग-अलग वर्गों में चीजों को लपेटने का फैसला कर सकती है (विशेष रूप से यदि कई विचार एक ही डेटा का उपयोग करते हैं) इसे विचारों को सौंपने से पहले, लेकिन इसका कोई मतलब नहीं है। –

2

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

+1

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

+0

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

+1

यदि यह एक प्रदर्शन/अनुकूलन मुद्दा है, तो जॉन फेमिनेला का उत्तर (इसे संभालने के लिए एक सेवा विधि बनाने के लिए) निश्चित रूप से उचित होगा। ऐसा कहकर, बहुत सारे OR/M टूल्स आपको इन गुणों को आलसी लोड करने देंगे (जो कि निश्चित रूप से मज़बूत है, अगर आप उनमें से किसी एक का उपयोग नहीं कर रहे हैं या अपनी डेटा एक्सेस लेयर/रिपोजिटरी रोलिंग नहीं कर रहे हैं)। –

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