डेल्फी डेटा-जागरूक घटकों का उपयोग करना - पेशेवरों और विपक्ष

Question

मैं परियोजनाओं में डेटा-जागरूक घटकों का उपयोग करने के बारे में आपकी राय जानना चाहता हूं। डेल्फी और डेटा-जागरूक घटकों (डेल्फी के मानक सूट या तृतीय पक्ष से) का उपयोग करके विकासशील अनुप्रयोगों (win32 और web) के 'ताकत' और 'कमजोर' बिंदु कौन से हैं?

फायरबर्ड का उपयोग करके मैंने आईबीओब्जेक्ट्स के साथ बहुत कुछ किया है, जो घटकों का एक परिपक्व सूट है और बहुत अच्छी तरह से काम करता है।

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

मुझे डीबी 2 (AS400) पर भी रूचि है। आपने सफलता के साथ किस घटक का उपयोग किया है, या कौन से घटक वास्तव में काम करने के लिए दर्द हैं?

Answer 1

मुझे पता चला है कि डेटा-जागरूक घटकों का उपयोग किसी एप्लिकेशन में व्यवसाय और यूआई तर्क के बीच कोई स्पष्ट अंतर नहीं है।

यह छोटी परियोजनाओं के लिए ठीक है, लेकिन जैसे ही वे बड़े होते हैं, कोड कम और कम बनाए रखने योग्य होता है।

घटना कोड (और उनकी बातचीत) के सभी विभिन्न बिट्स समझने के लिए एक असली दुःस्वप्न बन सकते हैं!

अनिवार्य रूप से ऐसे मामलों में मैंने डेटा-जागरूक घटकों को हटा दिया है और एक (हाथ-कोडित) एमवीसी डिज़ाइन पर स्विच किया है।

इसके लिए बहुत सारे अप-फ्रंट कोडिंग प्रयास की आवश्यकता होती है लेकिन परिणाम (आईएमएचओ) एक ऐसी परियोजना में है जो रखरखाव योग्य, एक्स्टेंसिबल और डिबगबल है।

Answer 2

ओआरएम समाधान पर नज़र डालें।

यह बहु-स्तरीय वास्तुकला के साथ एक अच्छा दृष्टिकोण है। देखें ORM for DELPHI win32

Answer 3

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

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

Answer 4

आप Unidac का उपयोग कर सकते हैं जो फ़ायरबर्ड (जो मैं उपयोग करता हूं) सहित कई डेटाबेस सर्वर का समर्थन करता हूं और इसमें बहुत अच्छी सुविधाएं हैं।

Remobject SDK के साथ युग्मित आपके पास एन-स्तरीय आर्किटेक्चर और डेटाबेस अबास्ट्रक्शन का अच्छा संयोजन होगा।

Answer 5

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

Answer 6

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

यह मुश्किल नहीं है, लेकिन आपको यह पता होना चाहिए कि आप यह कैसे कर सकते हैं।

एक दृष्टिकोण डेटामैट घटक (या अन्य गैर दृश्य कंटेनर) में आपके डेटासेट घटक रखना है।

एक और आसान चाल यूआई प्रविष्टि करने के लिए एक TClientDataSet का उपयोग करना है, और यूआई और व्यापार परत के बीच इंटरमीडिएट बफर के रूप में इसका उपयोग करना है। व्यापार परत तब आपके डेटा परत के लिए विशिष्ट TDataSet घटकों का उपयोग करती है।

--jeroen

Answer 7

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

डेटा अवगत घटक उपयोग के लिए मेरे सुझावों में से कुछ

• है सिर्फ एक बड़े पैमाने पर FishFact पुनर्लेखन नहीं हैं। अपने डिजाइन में कुछ विचार रखो।

• किसी TDataModule का उपयोग न करें, का उपयोग करें TDataModules प्रत्येक आपके एप्लिकेशन डेटा के केवल एक छोटे पहलू के लिए ज़िम्मेदार है।

• टीडीएसेट्स टीडीटा मॉड्यूल पर हैं, जबकि टीडीएटी स्रोत टीएफओआर पर हैं (जब तक मास्टर/विस्तार संबंधों के लिए उपयोग नहीं किया जाता है)।

• डेटा-स्नैप TClientDataSet जैसे मेमोरी डेटासेट का उपयोग करें।

• आपकी क्लाइंटडेटासेट्स को आपके डेटाबेस टेबल को बिल्कुल दर्पण करने की आवश्यकता नहीं है। DataSnap आपको स्मृति में अपने डेटा संरचनाओं को मालिश करने की अनुमति देता है ताकि आप विशिष्ट उद्देश्यों के लिए बनाए गए डेटासेट का उत्पादन कर सकें। विशेष रूप से आप की तरह

  • एक संपादन योग्य डाटासेट

  • में दो या अधिक तालिकाओं में शामिल होने से Denormalizing मास्टर विस्तार तालिका संरचनाओं कर सकते हैं, कभी कभी अपने यूआई कोड को आसान बनाने में कर सकते हैं।

  • में स्मृति केवल क्षेत्रों बनाएँ (गणना क्षेत्रों की तरह है, लेकिन आप भी उन्हें लिख सकते हैं)

• TClientDataSet नेस्टेड तालिकाओं उपयोगी नहीं बल्कि एक ही रास्ता मास्टर विस्तार रिश्तों को व्यक्त कर रहे हैं। कभी-कभी इसे दो स्वतंत्र TClientDataSets के साथ पुराने तरीके से करना बेहतर होता है जो TDataSource के माध्यम से जुड़ जाता है।