डीएओ पैटर्न और ओपन-क्लोज़ेड सिद्धांत

Question

मैंने देखा है और बहुत पुराने, जेडीबीसी-आधारित डीएओ कोड के साथ काम किया है जो आमतौर पर सीआरयूडी विधियों के साथ शुरू होता है। मेरा प्रश्न विशेष रूप से पुनर्प्राप्ति विधियों, या 'खोजकर्ता' से संबंधित है। आमतौर पर मैं क्या लगता है कि DAOs दो तरीकों के साथ शुरू होता है:

• खोजें और लौट सभी
• एक अद्वितीय पहचानकर्ता के आधार पर एक विशिष्ट उदाहरण को पुनः प्राप्त

प्रायः

, उन दो ढूँढ़ने वाले अपर्याप्त हैं मैं आमतौर पर एक डीएओ वर्ग बार-बार इस तरह का खोजक विधियों को जोड़ने के लिए संशोधित देखकर अंत:

• ढूंढें और सभी लौट जहां {हालत}

क्या होता है कि अधिक तरीकों जोड़ रहे हैं तब होता है जब एक नया { शर्तों को} समर्थित करने की आवश्यकता है या अतिरिक्त विधियों को समर्थन देने के लिए विधि के अंदर SQL क्वेरी को संशोधित करने के लिए झंडे के रूप में नए पैरामीटर जोड़ने के लिए मौजूदा विधियों को संशोधित किया गया है।

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

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

इस पर कोई विचार?

---

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

public abstract class Command<R>{ 
     public <R> execute(); 
     public void setArguments(CommandArguments args){ 
      //store arguments 
     } 
    } 

    //map based structure for storing and returning arguments 
    public class CommandArguments{ 
     public String getAsString(String key); 
     public String getAsInt(String key); 
     //... others 
    } 

    //In some business class... 
    Command command = CommandFactory.create("SearchByName"); 
    CommandArguments args = new CommandArguments(); 
    args.setValue("name", name); 
    // others 
    command.setArguments(args); 
    List<Customer> list = command.execute(); 

Answer 1

हम अपने डेटा परत ORM के लिए iBatis का इस्तेमाल किया है और विभिन्न क्षेत्रों आप paramaters के रूप में उपयोग करने के लिए इच्छा हो सकती है के साथ एक पैरामीटर वस्तु पारित करके लागू करने के लिए क्या आप एक क्वेरी में प्रस्तावित नहीं किए हों पाए हैं।

तब में खंड आप एक शर्त खंड के रूप में प्रत्येक क्षेत्र निर्दिष्ट कर सकते हैं अपने जहां

लेकिन केवल तभी जब पैरामीटर वस्तु में अपनी आबादी वाले। यदि परम ओब्जे में केवल एक फ़ील्ड शून्य नहीं है तो इसका एकमात्र ऐसा परिणाम होगा जो परिणामों को फ़िल्टर करने के लिए उपयोग किया जाएगा।

इस प्रकार आप अपने मापदंडों के फ़ील्ड्स जोड़ने के लिए आप सिर्फ एसक्यूएल और paramObj बदलने की जरूरत है। इसके बाद आपके पास 2 विधियां हो सकती हैं जो उत्तीर्ण पैरामीटर के कॉम्बो के आधार पर सभी या एक सबसेट लौटाती हैं, या कम से कम यह दृष्टिकोण आवश्यक प्रश्नों की संख्या को कम करेगा।

उदा। कुछ के साथ कुछ ...

SELECT * FROM MY_TABLE 
WHERE FIELD_ZERO = paramObj.field0 
<isNotNull property="paramObj.field1">AND FIELD_ONE = paramObj.field1</isNotNull> 
<isNotNull property="paramObj.field2">AND FIELD_TWO = paramObj.field2</isNotNull> 
<isNotNull property="paramObj.field3">AND FIELD_THREE = paramObj.field3</isNotNull> 

Answer 2

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

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