2012-01-19 11 views
12

में गैर डीबी जागरूकता नियंत्रणों के बजाय डीबी जागरूकता नियंत्रणों का उपयोग करने के क्या फायदे हैं। मैं एक दोस्त को राजी करता हूं कि डेल्फी में डेटाबेस घटक (डीबी जागरूकता नियंत्रण) का उपयोग करके डेटाबेस अनुप्रयोगों को विकसित करते समय अब ​​तक का सबसे अच्छा विकल्प है।डेल्फी

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

मेरे लिए यह ध्वनि कम से कम प्रतिद्वंद्वी है।

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

तो: कृपया मुझे डीबी जागरूकता नियंत्रणों के उपयोग के बारे में ध्वनि सलाह के साथ मनाने में मेरी सहायता करें!

आप सभी को अग्रिम धन्यवाद, जो कम से कम अपनी सलाह पोस्ट करेंगे, जो भी एक या दूसरे समाधान के पक्ष में होगा।

- फैबियो vitale

+7

+1 क्योंकि मुझे सवाल पसंद है, लेकिन मैं कभी भी उपयोग-डीबी-जागरूक-नियंत्रण शिविर में नहीं हूं, इसलिए मैं जवाब देने वाला नहीं हूं। –

+1

यह निर्भर करता है कि कौन सा नियंत्रण, डबिटिट इत्यादि ठीक है लेकिन कभी-कभी डब्रिड जैसी चीजें वांछित होने के लिए बहुत कुछ छोड़ती हैं – Simon

+4

+1 छोटे डीबी एप्लिकेशन (जिसे मुझे तेज़ समाधान की आवश्यकता है) के लिए मैं डीबी जागरूकता नियंत्रण के साथ जाऊंगा, खासकर यदि डीबी स्थानीय है (एमएस-एक्सेस की तरह)। बड़े पैमाने पर और पूर्ण डीबी अनुप्रयोगों के लिए मैं अपने स्वयं के गैर-जागरूक नियंत्रणों का उपयोग करना पसंद करता हूं। डीबीजीड के लिए उदाहरण के लिए मैं वर्चुअल ट्री का उपयोग करता हूं जहां डेटासेट को बाध्य नहीं किया जाता है। यह बहुत अधिक काम है लेकिन कम से कम मैं प्रतिबंधित नहीं हूं। – kobik

उत्तर

11

डीबी वाकिफ बनाम गैर डीबी वाकिफ एक अप्रचलित चर्चा की तरह है। डीबी-एवेयर नियंत्रणों में स्वचालित डाटाबेसिंग होती है, जिसका अर्थ है कि वे डेटा के साथ स्वयं को स्वत: भर देते हैं, पहचान बदलते हैं और डेटासोर्स के सदस्यों को लिखते हैं; गैर-डबवेयर नियंत्रण में, यह उन कार्यों को करने के लिए आप पर निर्भर है। इससे गन्दा कोड भी हो सकता है - या केवल डाटाबेसिंग करने के लिए अतिव्यापी ढांचे। दोनों परिदृश्य खराब हैं।

डेटा स्रोत की तरह और व्यक्तिगत नियंत्रण प्रदर्शन का निर्धारण करेगा की गुणवत्ता। मैंने देखा है कोड का एक बहुत TStringGrid DataBind को बस सिर्फ विशुद्धतावाद की वजह से (जब TDbGrid अच्छी तरह से करना होगा) TDBGrid से बचने के लिए - बस एक ज्यादा बेतुका समय के नुकसान।

यह एक अप्रचलित चर्चा बन गई जब TClientDataset डिस्कनेक्ट किए गए अनुप्रयोगों के लिए डी-फैक्टो डेटासेट बन गया: आप डेटा खींच सकते हैं, डिस्कनेक्ट कर सकते हैं, डेटा पर काम कर सकते हैं, फिर से कनेक्ट कर सकते हैं और परिवर्तन लागू कर सकते हैं। चूंकि सीडीएस + डीबीएवेयर नियंत्रण 99% इंटरफ़ेस करेगा, इसलिए आप अगले 1% (कुछ जटिल इंटरफेस के लिए) के लिए गैर-डेटा-जागरूक नियंत्रणों का उपयोग करते हैं। हां, तो अब सभी नियंत्रण db-जागरूक कर सकते हैं अगर अगर जरूरत -

मैं अभी भी अगर LiveBindings अच्छी तरह से OO डेटा बाइंडिंग का काम करते देखने के लिए XE2 जरूरत नहीं है।

संपादित करें: दा-मुलायम के जवाब में, वह (वह?) तर्क देता है कि डीबीएवेयर नियंत्रण एमवीसी पैटर्न लागू करता है और लचलन जी इस बात से असहमत है कि यह कोड भी एमवीसी नहीं है। मैं यहां अपना $ 0,02 सेंट दूंगा ;-)

मुझे लगता है कि डेटा मॉड्यूल और इकाई (जैसे ईआरडी में) में 1: 1 संबंध का उपयोग - या डेटा मॉड्यूल और एक फॉर्म - आप एक आवेदन प्राप्त कर सकते हैं जिम्मेदारियों अलग होती है:

  • रूप DFM -> लेआउट और डिजाइन समय डेटा बाइंडिंग (केवल datasources है)
  • प्रपत्र *।क़दम -> इंटरफेस को नियंत्रित करता है और डेटा (एक नियंत्रक की तरह कार्य करता है)
  • डाटा मॉड्यूल के लिए डेटा मॉड्यूल पूछता है -> तरीकों डेटा पुनर्प्राप्ति के लिए रूपों अनुरोध और डेटा अपडेट
  • जवाब देने के लिए

मैं सामान्य रूप से करने के लिए एक अलग डेटा मॉड्यूल है डेटाबेस कनेक्शन जो फॉर्म/इकाइयों के गुणों के माध्यम से पारित किया जाता है।

+2

+1 XE2 में लाइव बाइंडिंग का उल्लेख करने के लिए। TClientDataset का उल्लेख करने के लिए –

+2

+1 – LightBulb

10

डीबी जागरूक नियंत्रण पेशेवरों:

  1. काम एक नियंत्रण करने के लिए डेटा लोड और एक डाटासेट करने के लिए डेटा को बचाने के लिए VCL द्वारा किया जाता है। आपके पास कोड कम है - वास्तव में आरएडी।
  2. डीबी-जागरूक नियंत्रण + TDataSource + TDataSet एमवीसी पैटर्न लागू करता है। इससे जीयूआई और डेटा एक्सेस कोड को अलग करने में मदद मिलती है।
  3. कोड की अन्य पोस्ट प्रोसेसिंग को सत्यापित करने, सुधारने, कोड करने के लिए ईवेंट ईवेंट हैंडलर का उपयोग करके अच्छी तरह से परिभाषित क्षणों में बुलाया जाएगा। इससे ऐसे कोड को केंद्रीकृत करने में मदद मिलती है और उन स्थानों के साथ भ्रम से बचने के लिए जहां इसे रखा जाना चाहिए। और इसे कॉल करने के क्षणों के साथ भ्रम से बचें।

विपक्ष:

  1. यह एक सार्वभौमिक दृष्टिकोण नहीं है। आप गैर-टीडीएटासेट डेटा स्रोत पर डीबी-जागरूक नियंत्रण को बाध्य नहीं कर सकते हैं। डेल्फी XE2 में लाइव डेटा बाइंडिंग शुरू करने के साथ इस मुद्दे को हल किया गया था।
  2. इवेंट संचालित प्रोग्रामिंग कुछ डेवलपर्स के लिए भ्रमित हो सकती है। और टीडीटासोर्स, टीडीटासेट, टीएफआईल्ड कार्यक्रमों और वास्तुकला के ज्ञान की आवश्यकता है, और पेशेवरों (3) के साथ विवाद का कारण बनता है। खराब घटना संचालित कोड दुःस्वप्न हो सकता है।
+1

मैं डेटा-जागरूक नियंत्रण का प्रशंसक हूं लेकिन मैं आपके दूसरे समर्थक से असहमत हूं। यहां तक ​​कि यदि नियंत्रण एमवीसी को लागू करता है (और मुझे विश्वास नहीं है कि वे ऐसा करते हैं) जिसका मतलब यह नहीं है कि आपका कोड करता है। आपको डेटा-जागरूक नियंत्रण अनुप्रयोग को सही तरीके से ले जाने का प्रयास करना है, यह डेटा-जागरूक नियंत्रणों का उपयोग करने का स्वचालित परिणाम नहीं है। – LachlanG

+0

@LachlanG: डेल्फी एक प्रकार का एमवीसी-जैसा है यदि आप सही ढंग से TDataModule का उपयोग करते हैं: फॉर्म-> नियंत्रण + TDataSource; फॉर्म * .pas -> इंटरफ़ेस को कमांड करें और डेटा मांगता है; डेटा मॉड्यूल: फ़ॉर्म के अनुरोधों का उत्तर देने और पुनर्प्राप्त करने के लिए डेटा के तरीकों। –

+0

@FabricioAraujo: मैं दृढ़ता से असहमत हूं। कोई फर्क नहीं पड़ता कि आप उनका उपयोग कैसे करते हैं वे एमवीसी की तरह कुछ भी नहीं हैं। मैं यह नहीं कह रहा हूं कि एमवीसी डेटा-जागरूक घटकों की तुलना में जरूरी या बदतर है कि दोनों बहुत कम आम हैं। – LachlanG

8

दोनों डीबी जागरूक और गैर डीबी बारे में पता घटकों आवेदन आप किस तरह का विकास कर रहे हैं पर निर्भर करता है, फायदे और नुकसान हैं।

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

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

गैर-डीबी-जागरूक घटकों का उपयोग करना अधिक जटिल हो सकता है क्योंकि इसे अंतर्निहित तंत्र की बेहतर समझ की आवश्यकता होती है, लेकिन बहु-उपयोगकर्ता और वितरित बहु-स्तरीय वातावरण में यह किसी और चीज़ से कहीं बेहतर है। इसके अतिरिक्त, आप प्रस्तुति (UI) परत से डेटा-एक्सेस परत को अलग (और चाहिए) कर सकते हैं, जो बाद में आपको किसी अन्य प्रकार को बदलने के बिना एक उपप्रणाली (मॉड्यूल, परत) में परिवर्तन करने की अनुमति देगा।

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

यह है, जो प्रणाली का उपयोग करने का फैसला करने के लिए डेवलपर पर निर्भर है क्योंकि, जैसा कि मैंने कहा, यह सब आवेदन आप कर रहे हैं की किस तरह और किस वातावरण में काम करेंगे पर निर्भर करता है।

+1

+1 क्योंकि स्पष्ट रूप से नाम देने का एकमात्र उत्तर "[बहु-स्तरीय] (http://blog.synopse.info/post/2010/08/19/How-to-implement-multi-tier-architecture-in-our -एसक्लाइट 3-फ्रेमवर्क) "स्तरित वास्तुकला। संक्षेप में: डीबी-घटक नरक बनाए रखने और स्केल करने के लिए नरक हैं। और [सेवा ओरिएंटेड आर्किटेक्चर (एसओए)] के बारे में बात करने लायक है (http://blog.synopse.info/post/2010/07/18/DataSnap-like- क्लाइंट- सर्वर- जेसन-RESTful- सेवा-in- डेल्फी- 7-2010) दृष्टिकोण। आरएडी डीबी घटक 1 99 0 के देव हैं: प्रोटोटाइपिंग और छोटे ऐप्स के लिए यह अच्छा है, लेकिन व्यावसायिक अनुप्रयोगों के लिए, 21 वीं शताब्दी में इसे टालना है। मल्टी-स्तरीय के लिए –

+0

+1 भी। –

+0

'डीबी-जागरूक घटकों को डेटाबेस के निरंतर कनेक्शन की आवश्यकता होती है। केवल तभी सत्य यदि आप सीधे डेटा एक्सेस घटकों को नियंत्रण में लिंक करते हैं। अन्यथा, डीबी-कंट्रोल डेटा के लिए टीडीएएसओएसओएस से पूछेगा और यह जो भी हो, उससे आएगा ... –

0

उपाख्यान: एक डीबी जागरूक नियंत्रण एक बार हमारे InterBase डेटाबेस में गड़बड़: एक 'खाली' या अशक्त तारीख से संकेत मिलता है, तारीख संपादित नियंत्रण TcxDBDateEdit (ExpressQuantumGrid) एक नकारात्मक दिनांक मान है, जिसका शाब्दिक का प्रतिनिधित्व करता है का उपयोग करता है "01/00/0000 "।

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

+0

उपाख्यान: मैंने एक बार प्रतिलिपि बनाई और त्रुटि पेस्ट की और गलत फ़ील्ड को गलत फ़ील्ड में सेव किया। वास्तव में मैंने इसे एक से अधिक बार किया है। ;-) – LachlanG

+1

एक डेटटाइम पिकर एक प्रकार का नियंत्रण है जो दिखाता है कि प्रोग्रामर ने कितना सावधान (या लापरवाही) बनाया है। मैंने बहुत सारे डीबीएवेयर डीटीपी देखे हैं जो एक ** शून्य ** स्थिति को सही तरीके से संभालने में असमर्थ हैं। –

+0

LachlanG आउच :) – mjn

1

यह विजुअल बेसिक के साथ अनुभव से एक कैरियोवर हो सकता है। जैसा कि मुझे याद है, यहां तक ​​कि माइक्रोसॉफ्ट ने डेवलपर्स को उत्पादन कोड में डीबी-जागरूक नियंत्रणों का उपयोग न करने के लिए कहा है।

डेल्फी को कभी भी यह समस्या नहीं थी, लेकिन जैसा कि अन्य ने कहा है, यह आपके द्वारा बनाई जा रही परियोजना के प्रकार पर निर्भर करता है और आप प्रदर्शन के मुद्दों में भाग लेते हैं या नहीं।