asp.net - visual - माइक्रोसॉफ्ट विज़ुअल सी++




विजुअल स्टूडियो में 'वेब साइट' और 'प्रोजेक्ट' के बीच अंतर (8)

संभावित डुप्लिकेट:
एएसपी.नेट: वेब साइट या वेब एप्लीकेशन?

मैंने देखा है कि जब आप विजुअल स्टूडियो 2008 को फायर करते हैं और ' नई परियोजना ' -> ' नई वेब साइट ' के बजाय 'एएसपी.नेट वेब एप्लिकेशन' -> 'एएसपी.नेट वेब साइट' के बजाय ' नई परियोजना ' -> 'एएसपी.नेट वेब एप्लिकेशन' चुनते हैं तो आपको स्पष्ट रूप से एक अंतर होता है। '। उदाहरण के लिए यदि आप 'प्रोजेक्ट' चुनते हैं, तो आप .dll पर संकलित कर सकते हैं और प्रत्येक पृष्ठ को * .aspx.designer.cs codebehind फ़ाइल मिलती है।

1) हमारे पास इन दो अलग-अलग परियोजना प्रकार क्यों हैं?

2) आप कौन सा पसंद करते हैं?

3) मैं एक दूसरे को क्यों चुनूँगा?

4) * .aspx.designer.cs फ़ाइलों के साथ क्या सौदा है?


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

  2. मैं - और मेरा कार्यस्थल - वेब साइट प्रोजेक्ट पसंद करते हैं

  3. हमें पसंद है कि वेबसाइट की फाइलें फाइल सिस्टम में फाइलें हैं (उन्हें मैन्युअल रूप से जोड़ने की आवश्यकता नहीं है)

  4. कोई जानकारी नहीं

यहां दो लेख हैं जो मैंने दोनों के बारे में पाया:

http://damieng.com/blog/2008/02/07/web-site-vs-web-application

http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx

नोट: वेब परिनियोजन परियोजना के साथ वेब साइटों के साथ कई मुद्दों का समाधान किया गया है

अद्यतन: बिंदु 1 फिक्स्ड, वेब एप्लिकेशन पहले वहाँ था


1) 'वेब साइट' मॉडल को एएसपी.नेट 2.0 के साथ पेश किया गया था, 'वेब एप्लिकेशन' मॉडल मूल .net ढांचे का प्रोजेक्ट प्रकार था। दोनों के पास अलग-अलग उपयोग हैं (नीचे देखें)।

2) यह संदर्भ पर निर्भर करता है। एक अच्छा उदाहरण यह है कि यदि आप एक सॉफ्टवेयर उत्पाद बेच रहे हैं, तो आप 'वेब एप्लिकेशन' प्रोजेक्ट का उपयोग करना चाहेंगे क्योंकि यह स्वाभाविक रूप से साफ संकलित कोड के लिए खुद को उधार देता है।

3) ऊपर देखें, व्यक्तिगत वरीयता, रखरखाव विशेषताओं। एक दिलचस्प बात यह है कि एक 'वेब साइट' आपको ऐसा करने की अनुमति देती है जो आपको बहुत परेशानी में डाल सकती है, वेबसाइट चलने के दौरान नोटपैड में कोड-बैक (आमतौर पर एक * .cs या * .vb) फ़ाइल में मनमाने ढंग से परिवर्तन कर रही है।

4) डिजाइनर.cs फ़ाइल ऑटो-जेनरेट कोड को स्टोर करने के लिए उपयोग की जाती है। "यह कोड एक उपकरण द्वारा उत्पन्न किया गया था।"


उनके पास अलग-अलग उद्देश्य हैं।

एक वेबसाइट ऐसी सामग्री वाली साइट है जो समय के साथ बदल सकती है, यह पृष्ठ स्वयं बदल जाएगा। कोई वास्तविक प्रोजेक्ट फ़ाइल नहीं है और साइट को बस फाइलों के सेट के रूप में तैनात किया गया है।

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


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


मैं 2 की परिभाषा को डुप्लिकेट नहीं करूंगा, क्योंकि इसका अभी जवाब मिला है।

तो दूसरे पर एक का उपयोग क्यों करें?

वेब साइट आपको इसे PHP या क्लासिक एएसपी साइट की तरह व्यवहार करने देती है, जहां आप इनलाइन परिवर्तनों को तुरंत कर सकते हैं जो तुरंत प्रभावी हो जाते हैं।

पेशेवरों

  • आप सीधे वेब सर्वर पर साइट पर tweaks कर सकते हैं
  • तैनाती फ़ोल्डर की प्रतिलिपि के रूप में सरल है

विपक्ष

  • यदि आप लाइव साइट पर सही बदलाव नहीं कर रहे हैं, तो आप परिवर्तन प्रबंधन समस्याओं में शामिल हो सकते हैं, जहां आप अपनी सभी फाइलों को सिंक में रखना भूल जाते हैं
  • आप अपने अंतिम उपयोगकर्ताओं को प्रदर्शित रनटाइम सिंटैक्स त्रुटियां प्राप्त कर सकते हैं, क्योंकि चेक करने का एकमात्र तरीका मैन्युअल रूप से प्रत्येक पृष्ठ को चलाने के लिए है

वेब एप्लिकेशन आपको इस तरह से अधिक व्यवहार करने देता है कि आप डेस्कटॉप एप्लिकेशन कैसे करेंगे - एक मशीन पर संकलित एक तैनाती योग्य है।

पेशेवरों

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

  • क्योंकि आप इसे अपनी मशीन पर संकलित करते हैं, इसलिए उस बिंदु पर सब कुछ सिंटैक्स चेक हो जाता है *

विपक्ष

  • तैनाती थोड़ी अधिक शामिल है तो बस फ़ोल्डर को अपनी विकास मशीन से कॉपी करें। हालांकि "प्रकाशित" कमांड का उपयोग संकलन और प्रक्रिया को सरल बनाने की प्रक्रिया को सरल बनाता है जो वेब सर्वर पर फ़ाइलों की प्रतिलिपि बनाई जानी चाहिए।

  • आपकी मशीन, संकलित, और वेब सर्वर पर भेजे गए एक नए संस्करण पर कोई भी बदलाव करने की आवश्यकता है *

* एएसपीएक्स / एचटीएमएल फाइलें सिंटैक्स की जांच की जाती हैं अगर आप इसे अपने बिल्ड विकल्पों में चालू करते हैं। इन फ़ाइलों को सर्वर पर तब तक संपादित करना भी संभव है जब तक कि वे आपके प्रोजेक्ट में संकलित न हों।


यदि आपके काम को ओओ भाषा सुविधाओं (कक्षा पदानुक्रम, नामस्थान) का लाभ उठाने की आवश्यकता है या यदि आपको परियोजनाओं (डेटा एक्सेस, क्लास लिब इत्यादि) के बीच सामान्य कोड का पुन: उपयोग करने की आवश्यकता है तो वेब एप्लिकेशन प्रोजेक्ट जाने का एकमात्र तरीका है।

वेबसाइट प्रोजेक्ट (सुराग नाम में है) वेब अनुप्रयोगों के विपरीत गैर-जटिल 'ब्रोशरवेयर' साइटों (जहां पृष्ठों में स्थिर सामग्री शामिल है) के लिए केवल वास्तव में अच्छा है।


सरल उत्तर इस प्रकार हैं:

  1. नई वेब साइट - पृष्ठों के अनुरोध के दौरान सर्वर पर संकलित पृष्ठों के पीछे कोड बनाता है।
  2. नई वेब प्रोजेक्ट - पूर्व-संकलित पृष्ठों को एक या अधिक असेंबली (पूरी साइट भी) में बनाता है, और सर्वर पर तैनात किया जाता है।

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

परिदृश्य # 2 - यदि एक हैकर आपके असेंबली प्राप्त करता है, तो उन्हें अपमानित किया जाएगा। Obfuscated असेंबली दरार करने के लिए कठिन हैं। ये असेंबली पूर्व-संकलित हैं, इस प्रकार सर्वर पर लोड कम कर रहे हैं।

अधिक जानकारी के लिए:

वेब अनुप्रयोग परियोजनाओं का परिचय


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

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

आप कह सकते हैं कि वेब साइट मॉडल के साथ समस्याएं काफी बड़ी थीं कि एमएस ने हमें इसके बजाय वेब ऐप दिए। व्यक्तिगत रूप से मैं कभी भी डेमो कोड से परे किसी भी चीज़ के लिए उनका उपयोग नहीं करता ... वास्तव में मैं ऐसा भी नहीं करता।





visual-studio-2008