2009-12-02 10 views
6

मैं अपने जावा ईई वेब अनुप्रयोगों के लिए अपनी कंपनियों के आर्किटेक्चर के हिस्से को डिजाइन करने की प्रक्रिया में हूं। मैं एक मुखौटा और एक या अधिक डीएओ का उपयोग करने के कारणों पर बहुत स्पष्ट हूं। मेरी समस्या यह है:एक मुखौटा और एक डीएओ के बीच क्या पैटर्न फिट बैठता है?

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

मेरा निष्कर्ष यह है कि मुझे एक 'व्यापार वस्तु' जैसी पैटर्न की आवश्यकता है जो एकीकरण स्तर के लिए उपयुक्त है। मैंने चारों ओर देखा है और मुझे मिली सबसे नज़दीकी चीज़ (अभी भी मेरे दिमाग में बिल्कुल सही नहीं है) Sun Transfer Object Assembler pattern है।

या तो जावा ईई की मेरी समझ में कोई अंतर है या वहां एक पैटर्न है जो फिट होगा।

उत्तर

4

शायद एक mediator तुम क्या चाहते है:

एक वस्तु समाहित कि कैसे वस्तुओं का एक सेट बातचीत को परिभाषित करें। मध्यस्थ एक दूसरे को स्पष्ट रूप से संदर्भित करने से वस्तुओं को रखकर ढीले युग्मन को बढ़ावा देता है, और यह आपको स्वतंत्र रूप से उनकी बातचीत को अलग करने देता है।

तो आप का समन्वय करने के क्रम में एक DaoMediator उपयोग कर सकते हैं दो या अधिक DAO रों

+0

सभी उत्तरों पढ़ने के बाद मेरी भावना एक मध्यस्थ है जो हमारे लिए जाने का तरीका है। उत्तरों के लिए बहुत धन्यवाद। वे सभी बहुत ही जानकारीपूर्ण रहे हैं। –

2

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

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

0

मुझे लगता है कि यह आपके डीएएल और आपके बिजनेस लेयर के बीच डेटामैपर (या एडाप्टर) पैटर्न है, लेकिन बिना किसी ठोस समझ के मुझे यकीन नहीं हो सका।

1

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

शायद आप जो पैटर्न ढूंढने की कोशिश कर रहे हैं वह वास्तव में समृद्ध डोमेन ऑब्जेक्ट्स में एक कदम है?

0

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

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

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