अंतर

Question

संभव डुप्लिकेट:
ASP.NET: Web Site or Web Application?

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

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

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

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

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

Answer 1

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

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

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

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

• MSDN Article describing the differences
• Similar stackoverflow question

Answer 2

वे विभिन्न प्रयोजनों के लिए है।

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

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

Answer 3

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, वेब अनुप्रयोग था वहाँ पहले

Answer 4

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

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

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

पेशेवरों

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

विपक्ष को कॉपी के रूप में सरल है

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

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

पेशेवरों

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

• क्योंकि आप अपनी मशीन पर यह संकलन, सब कुछ वाक्य रचना उस बिंदु *

विपक्ष

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

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

* aspx/html फ़ाइलें यदि आप इस मोड़ पर ही वाक्य रचना की जाँच कर रहे हैं हालांकि आपके निर्माण विकल्पों में। इन फ़ाइलों को सर्वर पर तब तक संपादित करना भी संभव है जब तक कि वे आपके प्रोजेक्ट में संकलित न हों।

Answer 5

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

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

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

Answer 6

3) वेब अनुप्रयोग परियोजनाएं एमएसबिल्ड द्वारा निर्मित की जा सकती हैं। वेबसाइटें नहीं हैं (बहुत सारे ट्वीविंग के बिना)। यदि आप स्वचालित बिल्ड के साथ टीमसिस्टम का उपयोग करते हैं तो यह जाने का तरीका है।

Answer 7

बहुत कम अंतर है, और मैं अत्यधिक वेब साइट मॉडल का उपयोग कर की सिफारिश करेंगे।

मुख्य अंतर किसी वेबसाइट के लिए है, कुछ फ़ाइलों को कुछ निर्देशिकाओं में रखा जाना चाहिए (कोड फ़ाइलों को 'App_Code' निर्देशिका में रखा जाना चाहिए), इसके अलावा, यह बहुत सीधे आगे है।

यदि तैनाती के लिए संकलित कोड आपके लिए महत्वपूर्ण है, और आप एक एकल डीएलएल चाहते हैं (जब आप किसी वेब साइट के लिए सामान्य प्रकाशित करते हैं तो कई लोगों के विपरीत), तो आप यह जोड़ना चाहेंगे -ऑन: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx

Answer 8

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

एक पृष्ठ मॉडल के साथ

, यदि आप ऐसा नहीं कर सकते हैं। आप AppCode निर्देशिका में "ठूंठ" कक्षाओं का निर्माण, और अपने पृष्ठों में उन लोगों के उत्तराधिकारी द्वारा उसके चारों ओर पाने के लिए है, लेकिन फिर भी है कि आदर्श नहीं है, और जटिलता जोड़ें।

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

Nich

Answer 9

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

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

Answer 10

सरल जवाब इस प्रकार हैं:

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

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

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

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

Introduction to Web Application Projects

Answer 11

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