एएसपी.नेट एमवीसी में दृश्य फ़ाइल/निर्देशिका संरचना क्या होनी चाहिए?

Question

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

विचार निर्देशिका के तहत, उपनिर्देशिकाएं हैं। इन उपनिर्देशिकाओं के अंदर विचार हैं। मुझे लगता है कि उपनिर्देशिका नियंत्रकों के लिए मानचित्र है, और नियंत्रक अपनी उपनिर्देशिकाओं में निहित विचारों पर कार्य करते हैं।

क्या इन निर्देशिकाओं में किस तरह के विचार शामिल हैं, इसकी कोई उभरती उम्मीद है? उदाहरण के लिए, प्रत्येक निर्देशिका के लिए डिफ़ॉल्ट पृष्ठ index.aspx होना चाहिए? क्या पृष्ठ नामकरण सम्मेलन का पालन करें जैसे कि [नियंत्रक] .aspx, सूची [नियंत्रक] .aspx, आदि? या यह कोई महत्त्व नहीं रखता?

Answer 1

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

आइए नज़र:

public ActionResult NotAuthorized() 
    { 
     return View(); 
    } 

कोई दृश्य का नाम) कॉल में निर्दिष्ट किया गया है क्योंकि दृश्य (, ढांचा अनुमान होगा कि दृश्य फ़ाइल नाम कार्रवाई के रूप में ही किया जाएगा नाम। ढांचे में एक प्रकार है जिसे व्यूइंजिन कहा जाता है जो विस्तार की आपूर्ति करेगा। डिफ़ॉल्ट व्यूइंजिन WebFormViewEngine है, जो उस नाम को ले जाएगा और इसमें एक .aspx संलग्न करेगा। तो इस मामले में पूरा फ़ाइल नाम NotAuthorized.aspx नहीं होगा।

लेकिन फ़ाइल में कौन सा फ़ोल्डर मिलेगा? फिर, ViewEngine उस जानकारी की आपूर्ति करता है। WebFormViewEngine के साथ, यह दो फ़ोल्डर में दिखेगा: ~/दृश्य/साझा और ~/दृश्य/{नियंत्रक}

इसलिए यदि आपके नियंत्रक AccountController बुलाया गया था, उस में लगेगा ~/दृश्य/खाता

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

public ActionResult NotAuthorized() 
    { 
     return View("Foo"); 
    } 

ध्यान दें कि WebFormViewEngine के साथ, "दृश्य का नाम" आम तौर पर फ़ाइल नाम, कम विस्तार के रूप में ही है, लेकिन ढांचे की आवश्यकता नहीं है अन्य दृश्य इंजनों की।

इसी तरह, आपके पास अपने एप्लिकेशन को विचारों और गैर-डिफ़ॉल्ट फ़ोल्डरों को देखने का कारण भी हो सकता है। आप अपना खुद का व्यूइंजिन बनाकर ऐसा कर सकते हैं। मैं this blog post में तकनीक दिखाता हूं, लेकिन प्रकार के नाम अलग हैं, क्योंकि यह ढांचे के पहले संस्करण के लिए लिखा गया था। हालांकि, बुनियादी विचार अभी भी वही है।

Answer 2

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

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

• /आदेश/(यानीइंडेक्स)
• /आदेश/शो/123
• /आदेश/संपादित करें/123
• /आदेश/अद्यतन/123
• /आदेश/नई
• /आदेश/
• /आदेश बनाने/नष्ट/123

दृश्यों का विकल्प/मानकीकरण काफी हद तक निर्भर करता है कि आप अपने आवेदन को कैसे मॉडल करते हैं (स्पष्ट कहने के लिए) और आप कितनी अच्छी तरह से जाना चाहते हैं। जितना करीब आप अपने नियंत्रकों को अलग-अलग मॉडल वर्गों (खांसी ... संसाधन ... खांसी) में मैप करते हैं, उतना ही छोटा होगा जितना छोटा होगा और अधिक आसानी से आप कार्यों के एक मानक सेट का पालन करने में सक्षम होंगे (जैसा उपरोक्त उदाहरण में है)।

मुझे यह भी विश्वास है कि छोटे कार्य मॉडल मॉडल तर्क में अधिक से अधिक मॉडल व्यापार तर्क को धक्का देने में मदद करते हैं, जहां यह संबंधित है।