2011-03-25 16 views
8

एमएस-एक्सेस में विकसित एक मौजूदा मध्यम आकार का एप्लिकेशन है जिसका उपयोग वर्तमान में केवल 15 उपयोगकर्ताओं द्वारा किया जाता है। अब हम एक फिक्स में हैं कि क्या इस मौजूदा एमएस-एक्सेस एप्लिकेशन को खरोंच करना है और नेट (जैसे यह विंडोज या वेब हो सकता है) में समान कार्यक्षमताओं को विकसित करना है। चूंकि यह एक बड़ा एप्लीकेशन नहीं है, क्या हमारे पास कार्यक्षमता को .NET एप्लिकेशन में स्थानांतरित करने में कोई सकारात्मकता है? प्रदर्शन, सुरक्षा इत्यादि के संदर्भ में दोनों (नेट वीएस एमएस-एक्सेस) के बीच तुलना की सराहना की जाएगी। आवेदन को विकसित करने के फायदे भी सराहना करेंगे। नेट भी मेरी मदद करेगा।एमएस एक्सेस एप्लिकेशन से माइग्रेट करने के लाभ .Net एप्लिकेशन

+0

यह एक ऐसा सवाल है जो आम तौर पर प्रकाश से अधिक गर्मी उत्पन्न करता है, लेकिन आप यहां बहुत भाग्यशाली हैं और तीन बहुत ही उच्च गुणवत्ता वाले और स्वागत किए गए उत्तरों प्राप्त हुए हैं। –

उत्तर

13

आईएमएचओ एक सामान्य तुलना ".NET" बनाम "एमएस-एक्सेस" समझ में नहीं आता है। आप अपने वर्तमान आवेदन की तुलना अपने माइग्रेट किए गए एप्लिकेशन की अपेक्षित विशेषताओं/प्रदर्शन/सुरक्षा/आदि से कर सकते हैं, लेकिन आपको अपने आवेदन के विवरण और आपको लगता है कि आप अपना ".NET" पोर्ट कैसे डिज़ाइन करेंगे ।

आप देख रहे हैं जब कारणों प्रवास के प्रयासों का औचित्य साबित करने के लिए, आप अपने आप निम्नलिखित प्रश्न पूछें चाहिए:

  • है किसी को भी जो आसानी से पहुँच दृश्यपटल का उपयोग करके विकसित नहीं किया जा सकता अपने वर्तमान आवेदन में सुविधाओं लापता? .NET में बदलने का यह एक अच्छा कारण होगा।
  • भविष्य में रखरखाव कौन कर रहा है? एक सी # प्रोग्रामर जिसके पास वीबीए के साथ केवल थोड़ा सा अनुभव है, या एक अनुभवी एक्सेस प्रोग्रामर है जिसमें सी # के बारे में कोई जानकारी नहीं है या केवल थोड़ी सी जानकारी है? या आप किसी भी तरह के रखरखाव डेवलपर को चुनने के लिए पूरी तरह से स्वतंत्र हैं, तो इससे कोई फर्क नहीं पड़ता?
  • क्या आप अपने एक्सेस एप्लिकेशन के साथ एक विशिष्ट एमएस-ऑफिस संस्करण पर फंस गए हैं? या इसे आसानी से एक नए संस्करण में माइग्रेट किया जा सकता है? किसी विशिष्ट Office प्लेटफ़ॉर्म से स्वयं को अपनाने के लिए विकास प्लेटफॉर्म को बदलने का एक अच्छा कारण हो सकता है।
  • आपके बैकएंड के बारे में क्या? क्या आप इससे संतुष्ट हैं (यदि आप अपना फ्रंटएंड .NET पर जाते हैं तो भी आप बैकएंड के रूप में एक्सेस रख सकते हैं), या आपको वास्तविक क्लाइंट-सर्वर डेटाबेस की आवश्यकता है (ज्यादातर मामलों में आपके एक्सेस एप्लिकेशन को इसके लिए अग्रभाग के रूप में रखना संभव है एक पूर्ण .NET माइग्रेशन की तुलना में बहुत कम प्रयास के साथ)? एमएस-एसक्यूएल सर्वर जैसे सीएस डेटाबेस आपको अधिक समेकित उपयोगकर्ताओं की अनुमति देता है और इसमें एक बेहतर सुरक्षा मॉडल (प्रशासनिक ओवरहेड की लागत के लिए) है, लेकिन वास्तव में आपको कोई तर्क नहीं मिलता है कि आप फ्रंटएंड के रूप में एक्सेस क्यों नहीं रख सकते हैं।
  • आपके वर्तमान एप्लिकेशन में एक्सेस की "आरएडी" सुविधाओं में से कितनी उपयोग की जाती है (उदाहरण के लिए, एक्सेस फॉर्म होने की संभावना स्वचालित रूप से तालिका-जैसी मोड या रिपोर्टिंग क्षमताओं पर स्विच हो सकती है)। इनमें से कुछ सुविधाओं के लिए .NET ढांचे में हाथ में कोई तैयार समाधान नहीं है, आपको इसे अलग-अलग या तृतीय पक्ष टूल के साथ हल करना होगा। दूसरी तरफ, एक्सेस पर बने रहने का एक अच्छा कारण होगा।

संपादित करें: यहाँ योएल Spolsky

http://www.joelonsoftware.com/articles/fog0000000069.html

से एक 10 से अधिक वर्षों पुराने लेख जो कुछ हद तक इस विषय से संबंधित प्रतीत हो रहा है है। पूरी तरह से शुरू करने के लिए मौजूदा एप्लिकेशन को फेंकने के बारे में वह क्या सोचता है उसे पढ़ें।

+1

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

+1

यह वास्तव में एक उत्कृष्ट पोस्ट है। अगर मैं संभव था तो मैं इसे +10 दे दूंगा, क्योंकि यह वास्तव में पार्क से गेंद को हिट करता है। मुझे विशेष रूप से स्पॉल्स्की उद्धरण पसंद है, क्योंकि ग्राहकों से इस प्रश्न का सामना करते समय मैं लगातार एक बार उठता हूं। –

3

एमएस एक्सेस एक अच्छा मैच प्रतीत होता है जब आपका एप्लिकेशन डेटाबेस में डेटा रिकॉर्ड्स को देखने और संपादित करने के लिए एक उपकरण है जो सरल रूपों के साथ कड़े रूप से तालिकाओं के साथ मिलकर होता है और आपको कम्प्यूटेशनल तर्क में बहुत कम आवश्यकता नहीं होती है संपूरण प्रक्रिया।

मैंने जावा में वीबीए कोड, 10 फॉर्म, 50 टेबल और 80 प्रश्नों के बारे में 2000 लाइनों के साथ एक एमएस एक्सेस एप्लिकेशन को फिर से कार्यान्वित करना समाप्त कर दिया है क्योंकि इसमें बहुत सारे कंप्यूटेशंस और I/O डेटाबेस से संबंधित नहीं हैं।जावा एप्लिकेशन कोड के लगभग 18000 लाइनों में एक ही लक्ष्य प्राप्त करता है। सभी अलग-अलग डेटाबेस को एकीकृत करने के लिए किए गए प्रयास काफी थे। यह सी # या किसी अन्य .NET तकनीक के साथ थोड़ा बेहतर होगा, लेकिन महत्वपूर्ण नहीं है।

यह सब इस बात पर निर्भर करता है कि आपके एक्सेस एप्लिकेशन को क्या करने के लिए डिज़ाइन किया गया है।

2

एक्सेस करने के लिए .NET की तुलना करने के बजाय, मुझे संदेह है कि आपको वास्तव में तुलना करने की आवश्यकता है SQL सर्वर में डेटा संग्रहीत करने के लिए डेटा संग्रहित करना।

याद रखें कि निम्नलिखित संयोजन के सभी मान्य हैं:

  1. डाटा और Access में सामने के छोर
  2. पहुँच में संग्रहीत डेटा, सामने के छोर .net में लिखा एसक्यूएल सर्वर में संग्रहित
  3. डाटा, सामने Access में खत्म एसक्यूएल सर्वर, .net में सामने अंत में संग्रहीत
  4. डाटा

सामान्य तौर पर अगर आपके डेटाबेस और n उपयोगकर्ताओं की संख्या बढ़ रही है, लेकिन फ्रंट एंड की जटिलता नहीं है, मैं विकल्प 3 का सुझाव दूंगा। यदि डेटा और जटिलता दोनों बढ़ रहे हैं, तो यह पूरे हॉग के लायक हो सकता है और विंडोज/वेब .net में अपग्रेड कर सकता है। ऐप एसक्यूएल सर्वर मार रहा है और एक पूर्ण पुनर्लेखन कर रहा है। इसके लिए अधिक विशेषज्ञ कौशल और संभावित रूप से लंबे समय तक विकास के समय की आवश्यकता होगी, लेकिन निष्पादन के लिए अधिक लचीलापन और अधिक विकल्प की आवश्यकता होगी।

संबंधित मुद्दे