डाटाबेस लेयर डिज़ाइन प्रश्न

Question

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

उन आवश्यकताओं को देखते हुए, मैं एक अमूर्त वर्ग डेटाबेस कनेक्शन के साथ आया हूं। आंतरिक रूप से, मैं System.Data.Common.Data.DbConnection-class का उपयोग करता हूं, जो मुझे पहले से ही कुछ लचीलापन देता है।
जिन चीजों को ठोस उदाहरणों की आवश्यकता है (DbCommand उदा। के बजाय ओलेडबॉमैंड) को CreateDbCommand() जैसे अमूर्त तरीकों में छिपाया गया है। उप-वर्ग (AccessDbConnection की तरह) उनको लागू करते हैं और ठोस उदाहरण प्रदान करते हैं। वर्तमान में है कि (वर्ग नामों पठनीयता के लिए संक्षिप्त) इस पदानुक्रम की ओर जाता है:

  DatabaseConnection 
     /  |  \ 
AccessConn  MySqlConn  DB2Conn 

हालांकि, वहाँ कुछ आपरेशनों कि अंतर्निहित डेटाबेस प्रणाली के लिए विशिष्ट हैं, ऐसे सभी तालिका नाम पुन: प्राप्त करने के रूप में कर रहे हैं। डाटाबेस कनेक्शन-क्लास में एक अमूर्त विधि GetTableNames() को रखना गलत लगता है और उप-वर्ग इसे ओवरराइट करते हैं।

मैंने सोचा कि शायद मैं डेटाबेस टूल नामक एक और सार आधार वर्ग बना सकता हूं, वहां उन परिचालनों को घोषित कर सकता हूं और फिर उन्हें डेटाबेस कनेक्शन कनेक्शन के उप-वर्गों के समान उप-वर्गों में लागू कर सकता हूं। जिसका मतलब है एक AccessDbConnection के लिए, मैं भी एक वर्ग AccessTools आदि आदि होगा कि:

  DatabaseConnection      DatabaseTools 
     /  |  \     /  |  \ 
AccessConn  MySqlConn  DB2Conn AccessTools MySqlTools DB2Tools 

किसी तरह मैं वास्तव में इस विचार से रोमांचित नहीं कर रहा हूँ।

इस डिजाइन समस्या को हल करने के लिए आपको क्या विचार हैं? अपने समय के लिए पहले से

धन्यवाद और जवाब :)

चीयर्स

ईसाई

Answer 1

चूंकि आपको 100% ओओ शुद्धता रखने के लिए कोई अंक नहीं मिलता है, स्विंगलाइन क्रोध की सलाह का पालन करें। आप कक्षा को फिर से नामित करके इसे शुद्ध भी बना सकते हैं ;-)

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

http://www.codeproject.com/KB/cs/abstractsvsinterfaces.aspx
Interface or an Abstract Class: which one to use?

"आधार वर्ग में साझा कोड के बारे में क्या?" - यदि आप स्थिर कक्षाओं का उपयोग करते हैं और उन्हें कॉल करते हैं तो आप DRY रह सकते हैं (ओओ में कुछ प्रक्रियात्मक तकनीकों का उपयोग करने के लिए यह पाप नहीं है)।उपरोक्त स्टैक ओवरफ़्लो विषय में क्यू # 2 दिलचस्प लग रहा है लेकिन मैं इसके लिए झुकाव नहीं कर सकता।

Answer 2

बल्कि एक सार विधि की तुलना में

, क्यों एक है कि एएनएसआई मानक INFORMATION_SCHEMA विचारों का उपयोग तालिका नामों को पुन: प्राप्त लागू नहीं, और फिर इसे एक प्रदाता के लिए DatabaseConnection कार्यान्वयन में ओवरराइड करें जो एएनएसआई अनुपालन नहीं है?

इसके अलावा, मुझे एक डिजाइन बिंदु दृष्टिकोण से अमूर्त विधि दृष्टिकोण के साथ कुछ भी गलत नहीं दिख रहा है।

Answer 3

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

ConnectionFactory(ACSESS).getConnection().getTools().fetchSchema();