डीएओ पैकेज संरचना

Question

मैं जेडीबीसी (कोई वसंत, हाइबरनेट या कुछ और नहीं) का उपयोग कर जावा में कुछ सरल डीएओ लिख रहा हूं।

क्या डीएओ को उसी इंटरफेस के रूप में कार्यान्वित करना या उन्हें उप-पैकेज में रखना बेहतर है?

उदाहरण:

com.mycompany.myproject.dao.MyDao 
com.mycompany.myproject.dao.MyDaoImpl 

या

com.mycompany.myproject.dao.MyDao 
com.mycompany.myproject.dao.impl.MyDaoImpl 

आप उप पैकेज संरचना का सुझाव हैं, तो क्या आप किसी उप-पैकेज के नाम के सुझाव है? .impl? .sql? .jdbc?

यथार्थ रूप से, मेरे पास कई कार्यान्वयन नहीं होंगे। क्या मैं इसे अधिक इंजीनियरिंग कर रहा हूं?

Answer 1

किसी एप्लिकेशन को डिज़ाइन करते समय पैकेज में संरचना के मानक तरीका नहीं है, अनुभव आमतौर पर यह तय करने में मदद करता है कि हमारे पैकेज के लिए उचित नाम क्या हैं।

एक ही पैकेज में या अलग-अलग में अपने इंटरफेस के पैकेजिंग कार्यान्वयन के बारे में बस इस बारे में सोचें कि जावा स्वयं कैसे संरचित है: आमतौर पर एक कार्यान्वयन वर्ग उसी पैकेज में पैक किया जाता है, जिसका इंटरफ़ेस होता है, लेकिन यह हर समय नहीं होता है।

यदि आप एक ही डीएओ के कई कार्यान्वयन के बारे में थे तो उन्हें .jdbc, .jpa या .jdo उप पैकेज में संरचित होने का अर्थ होगा। यदि आपके पास केवल एक ही कार्यान्वयन होगा, तो आप दोनों विकल्पों को समझने के लिए कुछ तरीकों से समझ लेंगे (एक ही पैकेज या .impl उप पैकेज)।

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

अंत में यह आम सहमति तक पहुंचने के लिए (या आप और आपके साथियों) पर निर्भर करता है और निर्णय लेता है जो आपके विशिष्ट मामले में अधिक समझ में आता है।

संपादित

एक आवेदन आमतौर पर डीएओ इंटरफ़ेस प्रति एक कार्यान्वयन है और उस पर इंजीनियरिंग बिल्कुल नहीं है, यह सिर्फ मतलब नहीं है जेपीए के लिए और के लिए JDO कार्यान्वित ही डीएओ इंटरफेस के लिए । इंटरफ़ेस/कार्यान्वयन पद्धति का उपयोग कर के उद्देश्यों में से कुछ कम करने के लिए फिर से फैक्टरिंग, आदि नकली वस्तुओं के साधन के द्वारा परीक्षण ..

पुनश्च है: मैं आमतौर पर JDepend पर भरोसा करते हैं अधिकांश के रूप में चक्र से बचने के संकुल में अपने आवेदन कक्षाओं वितरित करने के लिए जैसा मेरे द्वारा किया जा सकता है।

Answer 2

मुझे नहीं लगता कि या तो बेहतर है, लेकिन इस मामले में मैं पहला विकल्प पसंद करता हूं। यह के समान पैकेज में ArrayList, LinkedList, आदि के साथ होगा।

hibernate जैसे अतिरिक्त ढांचे का उपयोग करते समय मैं MyDao और HibernateDao के साथ दूसरा विकल्प लागूकर्ता के रूप में पसंद करता हूं।

Answer 3

नामस्थान और संकुल केवल टकराव को रोकने के लिए मौजूद हैं। जब तक वे अद्वितीय नहीं होते हैं तब तक बेहतर नहीं होता है।

Answer 4

मैं आपके दूसरे विकल्प के साथ जाऊंगा (हालांकि कोई भी वास्तव में बेहतर नहीं है), क्योंकि यदि आप किसी अन्य प्रोजेक्ट में अपना इम्प्लाइज लेना चाहते हैं तो एक आयात आयात किया जाता है और रीफैक्टरिंग आपके आयात में तत्काल दिखाई दे सकती है।

यह अधिक इंजीनियरिंग नहीं है। वहाँ डीएओ का उपयोग करने के कई फायदे हैं:

1. यह अन्य कारणों
2. अपने कोड का परीक्षण से डेटाबेस का उपयोग decoupling करके अपने कोड की गुणवत्ता में सुधार आसान बना दिया है और आप एक महीन अनाज के साथ यह परीक्षण कर सकते हैं।
3. यदि कुछ दिन, आपको पता चलता है कि हाइबरनेट वास्तव में आपके लिए बहुत आसान है, तो यह आपके शेष कोड को प्रभावित नहीं करेगा।