डेल्फी में ओओपी शुरू करने के लिए मुख्य रूप से डेटाबेस विकास पर ध्यान केंद्रित करना कहां है?

Question

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

Answer 1

डेल्फी के पास कुछ डेटाबेस नियंत्रण हैं, जो आरएडी के लिए बहुत अच्छे हैं, लेकिन गुई से डेटाबेस को डीक्यूपल करना मुश्किल है।

आप आंतरिक संचार के लिए क्लाइंट डेटासेट (मिडास) का उपयोग कर सकते हैं। उनका उपयोग डेटा जागरूक नियंत्रणों के साथ किया जा सकता है और इसमें कई अन्य रोचक गुण हैं।

Answer 2

यदि आप वास्तव में अपना ऑब्जेक्ट दृढ़ता ढांचा लिखना चाहते हैं, तो मैं अत्यधिक tiOPF वेबसाइट पर दस्तावेज़ पढ़ने की सलाह देता हूं। खासकर concepts manual।

जब आप इस दस्तावेज़ को पढ़ रहे हों तो आपको वास्तव में टीओओपीएफ का उपयोग करने में रुचि हो सकती है। यह एक स्थिर और मजबूत दृढ़ता ढांचा है जो सभी प्रमुख डेटाबेस के साथ काम कर सकता है।

Answer 3

मैं इस कभी नहीं किया है, लेकिन ...

त्वरित वस्तुओं पर एक नज़र डालें।

डेल्फी में कक्षाओं/वस्तुओं को दृष्टि से बनाने के लिए, मॉडलमेकर (एक वाणिज्यिक समाधान) आज़माएं।

Answer 4

हमम। बड़ा सवाल, यह सामान मैनुअल में नहीं है :(वास्तव में इसका जवाब देने के लिए एक पुस्तक की आवश्यकता होगी। हालांकि यदि आप एक नया मोटाई शुरू कर रहे हैं? तो मेरी सलाह सूची, 10 साल बाद डेल्फी के साथ ऐसा करने के बाद, निम्नानुसार शुरू होगी:

आम तौर पर

में गहराई से सोचें इससे पहले कि आप शुरू क्या कार्यक्षमता आप संस्करण 1. के लिए की जरूरत है लेकिन घंटियाँ और संस्करणों 2 की सीटी और की संभावना को अनदेखा न करें 3.

डेटा को छोड़कर जागरूक नियंत्रण का उपयोग न करें सरल अलग उपयोगिता या बेस डेटा एंट्री स्क्रीन में।

कारण:

• वे तुरंत आपके GUI < -> डेटाबेस पृथक्करण को तोड़ते हैं।
• वे आपको उपयोगकर्ता-मित्रता परीक्षण में थोड़ा सा छोड़ देते हैं।
• वे स्पेगेटी कोड

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

तर्क:

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

जहाँ तक संभव गुण होते हैं कि टिककर खेल है जहाँ आप जटिलता और setters केवल अगर वे केवल नहीं पढ़ा जा सकता है छिपाने के साथ एक वस्तु के रूप में सब कुछ पैदा करते हैं। अपने स्वयं के गुणों का हमेशा उपयोग करने के लिए अपने आप को अनुशासन दें - एक त्वरित सार्वजनिक चर के साथ धोखा देने का सामान्य रूप से परिणामस्वरूप आप इसे बाद में संपत्ति के रूप में फिर से बनाते हैं।

डाटाबेस डिजाइन -> डेटाबेस जुदाई - एक किताब :)

जीयूआई < पढ़ें।

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

• एक तंत्र को पुनः प्राप्त करने या डाटा लोड करें
• एक तंत्र संपादित करने के लिए कि डेटा
• एक तंत्र डेटा
• डेटा को प्रदर्शित करने के लिए एक तंत्र को सहेजने के लिए ।

यह मैं लूसीली-युग्मित कहूंगा।

प्रत्येक डेटा तालिका या बारीकी से संबंधित तालिकाओं के समूह के लिए एकमात्र डेटामैड्यूल केवल पढ़ने-योग्य प्रश्नों, लिखने योग्य आदि के साथ बनाते हैं। एसक्यूएल को यथासंभव सरल रखें- मैंने अपना अंतिम ऐप ओरेकल से MYSQL में 2 दिनों में स्थानांतरित कर दिया - 150 संबंधित वस्तुओं के साथ तालिकाओं और फ्रेम संपादित करें :)। शुरुआत में अपने स्वयं के डेटामैड्यूल में सभी को एक पूल कनेक्शन से लिंक करें।

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

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

इस तरह से काम करना आपकी परियोजना बड़ी संख्या में फाइलें जमा कर सकती है लेकिन आप डेल्फी पर भरोसा कर सकते हैं और भरोसा कर सकते हैं - ओओ मॉडल बहुत मजबूत है और शायद ही कभी पकड़ा जाता है।

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

आखिरकार - यह सब बहुत काम है :(इसे पहली बार प्राप्त करना सिर्फ इतना नहीं होगा कि हम ईमानदार हों, इसलिए ऐप को बाहर निकालने के लिए अपने सुंदर ऑब्जेक्ट मॉडल से समझौता करने के लिए तैयार रहें, लेकिन बड़ी टिप्पणियां करें जहां और क्यों तुम यह किया है और कैसे यह बाद में फिर से सही करने के लिए।

गुड लक :)

Answer 5

Jazz SDK मूल्य प्रकार, OPF और एमवीपी फ़्रेमवर्क

Answer 6

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

पैटर्न पर कुछ अच्छी किताबें पाएं। आप उन्हें इस पथ को जारी रखने के रूप में अमूल्य पाएंगे और अक्सर संदर्भित किया जाएगा। मैं मूल बातें के लिए GOF और डेटाबेस के ऑब्जेक्ट मॉडल पक्ष के लिए Patterns of Enterprise Application Architecture का सुझाव देता हूं। इन पुस्तकालयों में अधिकांश अवधारणाएं इन पुस्तकों में चर्चा के पैटर्न पर आधारित हैं।

Answer 7

यदि आप ढांचे की तलाश में हैं, तो Data Abstract इस बात के लिए सबसे अच्छा टूल है।

Answer 8

तुम भी इसके अलावा http://tiopf.sourceforge.net/Doc/overview/index.shtml देख hcOPF