बड़े एमएस एक्सेस एप्लिकेशन को .Net की ओर ले जाने के लिए सर्वोत्तम अभ्यास?

Question

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

हमने अपने आवेदन को धीरे-धीरे .Net की ओर ले जाने का फैसला किया क्योंकि हम Visual Basic .Net से चिपके रह सकते हैं: भले ही यह यहाँ के अधिकांश डेवलपर्स के लिए एक नई भाषा है, लेकिन हमें VBA और VB6 में लागू कई दर्जन छोटी परियोजनाओं का गहरा ज्ञान है।

हमने पहले से ही अपने एप्लिकेशन की डेटा लेयर कार्यक्षमता को MS SQL सर्वर पर ले जाना शुरू कर दिया है, ताकि हर डेटा हेरफेर और खोज सीधे सर्वर पर की जाए।

हम जो देख रहे हैं, वह हमारे व्यापक जीयूआई को धीरे-धीरे आगे बढ़ाने के लिए सबसे अच्छा अभ्यास है (लगभग 500-600 अलग-अलग रूप शामिल हैं, बहु-भाषा समर्थन आदि के साथ लगभग 200 रिपोर्ट)। डीएमएस में दस्तावेजों पर अतुल्यकालिक डेटा एन्क्रिप्शन को लागू करने के लिए हमारे संभावित ग्राहक के हालिया अनुरोध के बाद हम एमएस एक्सेस से इस हिस्से को पूरी तरह से समाप्त करने और इसे नेट में लागू करने के लिए भी खुश होंगे।

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

---

संपादित करें:

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

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

हमने मुख्य रूप से क्या किया है, एमडीबी प्रारूप में सीधे एमएस एक्सेस डेटाबेस तक पहुंचने के लिए हमने ADO.NET का उपयोग किया है और कुछ संसाधित डेटा के साथ तालिका पॉप्युलेट करें (जैसे ऊपर दिए गए उदाहरण से मेल संदेशों के बारे में डेटा: हमारे पास FROM, TO, CC, BCC, के लिए फ़ील्ड हैं) विषय और शरीर)।

.Net से MDB डेटा प्रारूप के साथ काम करने के लिए बिल्कुल कोई समस्या नहीं है , इसके अलावा, हम MDB के साथ नहीं रहना चाहते हैं और MS SQL Server 2008 के लगभग सभी चीज़ों को अपग्रेड कर दिया है - इससे हमें डेटा प्रबंधन और स्केलेबिलिटी के संबंध में बहुत अधिक स्वतंत्रता मिलती है।

यहां मुख्य समस्या यह है कि हम एक्सेस में "कॉलबैक" के एक प्रकार को लागू करना नहीं जानते हैं ताकि हम डेटा अपडेट पर कुछ VBA कोड के निष्पादन को ट्रिगर कर सकें।

MS Access 2010 सपोर्टिंग अपडेट और डेटा टेबल के लिए ट्रिगर्स सम्मिलित करने के साथ हमें बहुत उम्मीदें थीं , लेकिन यह पता चला कि हम केवल इन ट्रिगर्स के लिए MS Access मैक्रोज़ का उपयोग कर सकते हैं और ट्रिगर के भीतर किसी भी कस्टम VBA कोड को निष्पादित करने का कोई तरीका नहीं है।

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

हमने MS प्रवेश के लिए DDE में भी देखा, लेकिन हम DDE आदेशों को लागू करने और इन-मेमोरी डेटा और कमांड एक्सचेंज के लिए उपयोग करने का कोई अच्छा नमूना समाधान नहीं ढूंढ सके ।

तो, मुख्य समस्या एमएस एक्सेस और .नेट एप्लीकेशन का सह-अस्तित्व और एक-दूसरे के साथ सहभागिता करना है।

EDIT2 :

मैं यह उल्लेख करना भूल गया कि हमने .NET और MS एक्सेस के बीच संदेश भेजने के लिए VBA में MSMQ लाइब्रेरी को क्या लागू किया है , समस्या फिर से यहाँ कॉलबैक की कमी थी: हमें वास्तव में नए संदेशों के लिए कतार का चुनाव करना पड़ा और यह देखते हुए कि VBA वास्तव में समर्थन नहीं करता है बहु सूत्रण यह वास्तव में एक अच्छा समाधान नहीं था।

Comments

क्या आपने एक छोटा सा प्रूफ-ऑफ-कॉन्सेप्ट .NET ऐप किया है, यह देखने के लिए कि आप दो हिस्सों को कितना अच्छा सहयोग कर सकते हैं? आपको किन समस्याओं का सामना करना पड़ा?

— sq33G

आपके एक्सेस एप्लिकेशन को कैसे तैनात किया जाता है? और प्रमाणीकरण तकनीक क्या है?

— स्कॉलर

@ sq33G: मैंने इन विषयों को संबोधित करने के लिए अपना प्रश्न संपादित किया।

— अलेक्जेंडर गल्किन

@ Skrol29: हम आमतौर पर इसे MS Access रनटाइम के साथ संकलित MDB (.MDE) के रूप में तैनात करते हैं। हम डेटाबेस कनेक्शन और अनुमतियों के लिए सक्रिय निर्देशिका के माध्यम से प्रबंधित विंडोज प्रमाणीकरण का उपयोग करते हैं।

— अलेक्जेंडर गल्किन

बड़ा सवाल है। यह एक बहुत ही व्यावहारिक समस्या है कि बहुत सारी गैर-सॉफ़्टवेयर कंपनियां, जो जल्दी से बढ़ती हैं, अक्सर सामना करती हैं और डेवलपर्स की गोद में फेंक दी जाती हैं - जब "सब कुछ करते हैं" एक्सेस डेटाबेस उनकी बढ़ती जरूरतों का पैमाना नहीं हो सकता।

— bunglestink

Answer 1

यह एक बड़ी और शामिल परियोजना है। मैं कई बार .NET के एक्सेस डेटाबेस को माइग्रेट करने के लिए जिम्मेदार रहा हूँ, लेकिन इस पैमाने पर कभी नहीं। मैं मानता हूं कि एक क्रमिक दृष्टिकोण शायद सबसे यथार्थवादी होगा। एक शॉट में सब कुछ लेने की कोशिश करना विफल होने का एक आसान तरीका है।

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

अगला, "स्व निहित" अनुप्रयोग के मॉड्यूल की पहचान करें। चूँकि यह एक डू-एवरीथिंग डेटाबेस है, संभवतः इसके मॉड्यूल ऐसे होंगे जो एक दूसरे से लगभग पूरी तरह से असंतुष्ट हैं। इन असंतुष्ट टुकड़ों के होने के बाद, उन छोटे मॉड्यूलों में से एक की पहचान करें जिन्हें अपडेट होने से सबसे अधिक लाभ होता है, और इसे पहले ले लें।

.NET पर माइग्रेट करते समय, एप्लिकेशन की सरल 1 से 1 कॉपी न करें। वर्तमान एप्लिकेशन के साथ दर्द बिंदुओं की पहचान करने के लिए उपयोगकर्ताओं से इनपुट इकट्ठा करें। आप चाहते हैं कि आपकी पहली माइग्रेशन इकाई अन्य सभी से पूर्ण खरीद प्राप्त करने के लिए एक बड़ी सफलता हो।

आपके द्वारा की गई पहली इकाई के बाद, चुनौतियों, कठिनाइयों आदि के संदर्भ में जो कुछ हुआ है, उसे देखें और आगे बढ़ने के लिए इसका उपयोग करें।

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

Comments

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

— रामहुंड

Answer 2

यहाँ आपके एमएस एक्सेस एप्लिकेशन को म्यूटेशन द्वारा VB.Net एप्लिकेशन में बदलने की योजना है।

यह एक सामान्य योजना नहीं है, निम्न योजना आपके द्वारा वर्णित परियोजना पर निर्भर करती है।

चरण 1: सभी डेटा को SQL सर्वर पर माइग्रेट करें

कनेक्शन के लिए ODBC का उपयोग न करें SQL सर्वर तक पहुंच के बजाय, एक्सेस प्रोजेक्ट (ADP) का उपयोग करें। एक एक्सेस प्रोजेक्ट एक .adp एक्सटेंशन के साथ एक एक्सेस फ़ाइल है, इसमें पूर्ण एक्सेस फीचर (मैक्रोज़, फ़ॉर्म, रिपोर्ट, मॉड्यूल) हैं, लेकिन कनेक्शन एमडीबी फ़ाइल के बजाय सीधे SQL सर्वर डेटाबेस पर है। एडीपी फाइलें एमडीबी फाइलों के साथ बहुत संगत हैं। वे एक्सेस 2010 में समर्थित नहीं हैं, जबकि वास्तव में यह सुविधा छिपी हुई है, लेकिन यह बहुत अच्छी तरह से समर्थित है। एमडीई की तरह, एडीपी फाइलें एडीई फाइलों में "संकलित" हो सकती हैं।

SQL सर्वर में माइग्रेट करने से डेटा संरचना और कोड में कुछ संशोधनों का खर्च आएगा, लेकिन सभी को स्थानांतरित करना काफी आसान है। और यह एक अंतिम लक्ष्य है।

डेटाबेस ईवेंट को VBA या VB.Net कोड को ट्रिगर करने के बारे में भूल जाएं। यह तकनीकी रूप से SQL सर्वर एक्सटेंडेड स्टोर्ड प्रोसीजर का उपयोग करके किया जा सकता है, लेकिन यह बहुत ही बुरा ट्रिक है। आपकी परियोजना में भविष्य का जीवन है, इसलिए इस तरह के विनाशकारी पुल से बचकर इसकी डेटा संरचना को लागू करना बेहतर है। सामान्य तौर पर, डेटाबेस ट्रिगर के साथ खेलते हैं, यह स्मार्ट है लेकिन बनाए रखने के लिए काफी मुश्किल है।

चरण 2: प्रमाणीकरण को एक समान बनाएं

यह अच्छी बात है कि आपका एप्लिकेशन एक्सेस सिक्योरिटी (MDW फ़ाइल) पर आधारित नहीं है।

VB.Net अनुप्रयोग के लिए लक्ष्य प्रमाणीकरण के लिए एक योजना बनाएं, और फिर दो अनुप्रयोगों के बीच एक समान प्रमाणीकरण होने के लिए इस लक्ष्य तक पहुँच प्रमाणीकरण को स्थानांतरित करने का एक तरीका निर्धारित करें।

चूंकि प्रमाणीकरण एक एप्लिकेशन आर्किटेक्चर में अनुप्रस्थ है, इसलिए एक्सेस संस्करण के बीच VB.Net संस्करण में स्लाइस करना अधिक आसान होगा।

चरण 3: एक्सेस और VB.Net के बीच एक पुल बनाने के लिए एक टोकन सुविधा तैयार करें

आपने कहा, Access UI में कुछ सटीक मापदंडों के साथ VB.Net UI खोलना होगा और प्रमाणीकरण भी होगा। और आपको शायद दूसरे तरीके से भी ऐसा ही करना पड़ेगा।

एक अच्छा समाधान एक टोकन तालिका के आधार पर एक छोटी टोकन सुविधा का निर्माण करना है: कॉलम एक टोकन आईडी (पूर्णांक), एक टोकन कुंजी (लंबी स्ट्रिंग), एक टोकन तिथि और एक पैरामीटर सूची (लंबी स्ट्रिंग या पाठ) हो सकती है। हर बार एक्सेस को VB.Net स्क्रीन खोलने की आवश्यकता होती है, फिर मापदंडों के साथ डेटाबेस में एक टोकन को सहेजें, और फिर केवल टोकन आईडी और टोकन कुंजी के साथ अपना VB.Net एप्लिकेशन खोलें। VB.Net खुलता है, डेटाबेस में टोकन आईडी खोजता है, कुंजी की जांच करता है (यह प्रमाणीकरण के रूप में लागू होता है) और मापदंडों को पढ़ें। फिर यह इसी रूप में खुलता है, और जो आवश्यक होता है वह करते हैं। टोकन की अवधि देना और पुराने टोकन को साफ करना न भूलें।

यदि आपको VB.Net से एक्सेस तक कॉलबैक करने की आवश्यकता है (आप शायद करेंगे), तो मुझे लगता है कि ओएलई का उपयोग करके एक खोला एमडीबी एक्सेस फ़ाइल पर कुछ वीबीए कोड को सक्रिय करना संभव है।

चरण 4: माइग्रेट करें UI और मॉड्यूल स्क्रीन द्वारा स्क्रीन, मॉड्यूल द्वारा मॉड्यूल

अब तैयारी बड़ी की है। आप उपयोगकर्ता इंटरफ़ेस को Ms Access से VB.Net पर माइग्रेट करना प्रारंभ कर सकते हैं।

ऐसा करने के लिए कोई अच्छा स्वचालित उपकरण नहीं है। VBA और .Net बहुत अलग हैं। आपको इस तरह के प्रवास के लिए अपना काम तैयार करना होगा। छोटे रूप से शुरू करें, जैसे "लगभग" बॉक्स, और सरल रूपों से जटिल रूपों तक जारी रखें। बेशक आपको कुछ माइग्रेशन को बंडल और शेड्यूल करना होगा, लेकिन आप धीरे-धीरे अपनी स्क्रीन, रिपोर्ट और लाइब्रेरी को Ms Access से VB.Net पर माइग्रेट करेंगे।

Answer 3

मुझे आश्चर्य है कि आपने एक्सेस के साथ वह सब किया। एक बहुत ही महत्वपूर्ण प्रश्न है जो आप .NET विंडोज फॉर्म या .NET WPF से नहीं पूछ रहे हैं। WPF में स्टेटर लर्निंग कर्व है लेकिन मेरी राय में यह बेहतर UI के साथ अधिक शक्तिशाली है। हमने हाल ही में अपने व्यावसायिक एप्लिकेशन को फ़ॉर्म से WPF में बदल दिया है और हम पहले से ही अधिक बिक्री कर रहे हैं। हमने नई सुविधाएँ भी जोड़ीं लेकिन WPF UI सिर्फ सेक्सियर है। अपनी तालिका डिज़ाइन की समीक्षा करें और उसे साफ़ करें - अब समय है। सुनिश्चित करें कि आप सभी को FK घोषित कर रहे हैं। एक्सेस में आप फ्लाई पर सामान को कुछ आसान जोड़ सकते हैं जो सामान फिसल जाता है। यदि यह आपका पहला WPF UI कुछ प्रोटोटाइप का निर्माण करता है। हम WPF में और अधिक पैक कर सकते हैं कि नए ऐप में अधिक सुविधाएँ, कम स्क्रीन और बहुत कम कोड है। आप XAML से नफरत करते हैं कि इसे कितना प्यार करेंगे। MVVM जैसी संरचना पर विचार करें।

Comments

हमने WinForms, WPF और Silverlight (दोनों RIA और आउट-ऑफ-ब्राउज़र के रूप में) का उपयोग करते हुए कई छोटे .Net एप्लिकेशन विकसित किए हैं और मैं इस बात से सहमत हूं कि WPF (और सिल्वरलाइट) अनुप्रयोगों के लिए बहुत कामुक रूप और अनुभव प्रदान करता है।

— अलेक्जेंडर गल्किन

Answer 4

चूंकि आपको पहले से ही एक्सेस ऑब्जेक्ट मॉडल की अच्छी समझ है, इसलिए मुझे लगता है कि आप अपने .NET ऐप से एक्सेस इंटरॉप का उपयोग करना चाहते हैं । यह (अधिक या कम) आपको DDE की अपारदर्शिता के बिना एक एक्सेस ऐप के नियंत्रण को स्वचालित करने की अनुमति देता है।

Comments

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

— jfrankcarr

Answer 5

मुझे आपके व्यावसायिक तर्क परत के बारे में गहरी जानकारी नहीं है, लेकिन आप अपने MS Access डेटाबेस को अपने .NET अनुप्रयोग में भी एक्सेस कर सकते हैं। यदि यह केवल डेटा लाने के बारे में नहीं है, तो आप अपने कार्यक्रमों (VB6 और VB.NET एप्लिकेशन) के बीच एक टीसीपी / आईपी कनेक्शन लागू कर सकते हैं। कृपया कोडप्रोजेक्ट पर एक लेख देखें ।

Comments

"... इस एप्लिकेशन और चल रहे एमएस एक्सेस एप्लिकेशन के बीच डेटा विनिमय सक्षम करें।" यदि वह कथन मेरे उत्तर से संबंधित नहीं है। तब मुझे कुछ भी पता नहीं है।

— उस्मान तुरन

ठीक है। मैं क्षमाप्रार्थी हूं। डाउनवोट हटा दिया गया।

— आर्सेनी मूरज़ेंको

@ मेनमा: कोई बात नहीं।

— उस्मान तुरन

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

— उस्मान तुरन

लगता है कि आप की तुलना में यह एक बड़ी समस्या है :) क्योंकि, मेरी प्रत्येक टिप्पणी के बाद, आपने कुछ नया प्रकट किया। मैं MSMQ BTW से परिचित नहीं हूँ। माफ़ कीजिये।

— उस्मान तुरन

Answer 6

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

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

Answer 7

हमने धीरे-धीरे अपने आवेदन को .Net की ओर ले जाने का फैसला किया

अक्सर एक गलती। सबसे अच्छा अभ्यास "धीरे-धीरे" कोशिश नहीं करना है।

भले ही यह यहां के अधिकांश डेवलपर्स के लिए एक नई भाषा है, लेकिन हमें VBA और VB6 में लागू कई दर्जन छोटी परियोजनाओं का गहरा ज्ञान है।

निर्णय के लिए बहुत अच्छा आधार नहीं। यदि आप एक नई भाषा सीखना चाहते हैं, तो VB न सीखें। जावा की तरह C # या कुछ और भी बेहतर सीखें।

"यहां के अधिकांश डेवलपर्स के लिए एक नई भाषा, हमारे पास VBA का गहरा ज्ञान है" "हमारे पास एक VBA गुरु है जिसे हम चिढ़ाना नहीं चाहते" के लिए एक सामान्य कोड वाक्यांश है। यह कुछ ऐसा है जो संभवतः बुरा भी है।

हम जिस चीज की तलाश कर रहे हैं वह हमारी व्यापक जीयूआई को धीरे-धीरे आगे बढ़ाने के लिए सर्वोत्तम अभ्यास है

सर्वोत्तम प्रथाओं में "क्रमिक" शामिल नहीं है। वे "पूरी तरह से त्यागें" शामिल हैं।

क्रमिक पलायन जो मैंने देखा है वह टूट गया है क्योंकि यह बहुत कठिन है।

ऐसा करने से आप बेहतर हैं।

1. सबसे मूल्यवान संपत्ति संरक्षित करें । आँकड़े। सभी डेटा को SQL सर्वर पर ले जाएं। यह सब। SQL सर्वर के लिए ODBC कनेक्शन का उपयोग करने के लिए सभी MS-Access को फिर से लिखें। अभी।

2. किसी को भी जो अस्थायी टेबल या डेटा या एमएस-एक्सेस में कुछ भी बनाता है आग। सभी डेटा को MS-Access के बाहर डेटाबेस में रहना चाहिए। MS-Access में डेटा समस्याएँ पैदा कर रहा है, इसलिए अब रुकें और सुनिश्चित करें कि सभी सहमत हों। यदि वे सहमत नहीं हैं, तो उन्हें एक नया काम खोजें जिसमें MS-Access में हैकिंग शामिल नहीं है जबकि आप MS-Access से छुटकारा पाने की कोशिश कर रहे हैं।

3. एक रिपोर्टिंग ढांचा खोजें जो आपके पास अब आपके पास मौजूद रिपोर्ट उत्पन्न करेगा। कोई प्रोग्रामिंग नहीं। बस इसे एक टेबल या एक दृश्य और बैंग दें! हॊ गया।

4. सभी 500 रिपोर्टों की गणना करें। उन्हें उन रिपोर्टों में विभाजित करें जो आसानी से उपकरण के साथ निर्मित हैं और रिपोर्ट जो कठिन हैं। हार्ड वालों को "मस्ट हैव", "हैव है", "हैव हो सकता है" और "वॉट डू डू टु लेटर" को प्राथमिकता दें। स्वचालित रिपोर्टों को बदलें और इस रिपोर्टिंग टूल को MS-Access के बाहर पूरी तरह से रिपोर्ट करना होगा।

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

5. एक विकास ढांचा खोजें जो सीआरयूडी लेनदेन को स्वचालित रूप से बनाता है।

6. अपने 200 रूपों को CRUD रूपों (जो स्वचालित रूप से निर्मित किया जा सकता है) और गैर-CRUD रूपों में विभाजित करें। गैर-सीआरयूडी में, MoSCoW (मस्ट, चाहिए, कैन, वॉन्ट) नियमों का उपयोग कर प्राथमिकता दें।

   अक्सर, 60-80% आवेदन फॉर्म सरल, स्वचालित सीआरयूडी फॉर्म होते हैं। 20-40% अधिक जटिल हैं और अधिक कुशल प्रोग्रामिंग की आवश्यकता है। इसके आधार पर, आपके पास 120 से 160 CRUD फॉर्म हैं जिन्हें आपको फिर से लिखने की जरूरत नहीं है, बस स्वचालित करें। आपके पास 40-80 गंभीर रूप से जटिल लेनदेन हैं।

7. CRUD प्रपत्र और गैर-CRUD प्रपत्र बनाएँ।

8. अंतराल का मूल्यांकन करें। "से-हैव" सूची के सबसे महत्वपूर्ण हिस्सों पर फिर से प्राथमिकता दें और काम करना शुरू करें।

एक्सेस को पूरी तरह से छोड़ना शायद सबसे आसान है। क्रमिकता से बचें।

आप अंततः सारा पैसा खर्च करने जा रहे हैं।

आप इसके लिए बजट भी तैयार कर सकते हैं और अब इसे खर्च कर सकते हैं।

सह-अस्तित्व को प्रबंधित करने की कोशिश की जटिलता के कारण धीरे-धीरे ऐसा करने की कोशिश करना वास्तव में अधिक महंगा हो सकता है ।

Comments

यह सब अच्छा है, लेकिन यथार्थवादी नहीं है। विशेष रूप से "किसी को भी फायरिंग" और "पूरी तरह से त्यागने" वाला हिस्सा। हम वित्तीय और रणनीतिक और व्यक्तिगत दोनों दृष्टिकोणों से, हर चीज को फेंक नहीं सकते हैं और हरे क्षेत्र से शुरू कर सकते हैं।

— अलेक्जेंडर गल्किन

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

— सोयालेंटग्रे

क्षमा करें -1 अक्सर गलती के लिए यह था । सबसे अच्छा अभ्यास "धीरे-धीरे" कोशिश नहीं करना है। - क्या आपके पास इस 'सर्वोत्तम अभ्यास' के लिए एक प्रशस्ति पत्र है? क्योंकि ज्यादातर लोग इसके विपरीत कहेंगे - joelonsoftware.com/articles/fog000000006969.html

— MattDavey

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

— एस.लॉट

@ S। मुझे लगता है कि यह कहना चरम है कि कोड एक मूल्य से अधिक देयता है। ओपी ने कुछ भी नहीं कहा कि यह काम नहीं करता है या व्यावसायिक जरूरतों को पूरा नहीं करता है - वास्तव में "हम आवेदन की वर्तमान कार्यक्षमता से काफी संतुष्ट हैं" । कोई पूरी तरह से काम कर कोड बिन करने के लिए एक तत्काल जरूरत नहीं लगती - कोई कैंसर नहीं है। लेकिन ओपी ने पहचान की है कि भविष्य में सुधार करने के लिए उसे एक्सेस द्वारा लगाए गए कांच की छत के माध्यम से तोड़ने की आवश्यकता है - यह एक क्रमिक प्रक्रिया हो सकती है।

— मत्तीवेदी