कारण वेब अनुप्रयोग

Question

के लिए MVC वास्तुकला का उपयोग नहीं अतीत में मैं मुख्य रूप से एक एन-स्तरीय संरचना का उपयोग करते हुए, BLL और दाल परतों को लागू मेरे सारे वेब अनुप्रयोगों का निर्माण किया है। हाल ही में, मैंने कुछ आरओआर विकास करने के साथ ही एएसपी.नेट एमवीसी की तलाश शुरू कर दी है।

मैं विभिन्न आर्किटेक्चर (कुछ अन्य एसओ पोस्ट द्वारा संदर्भित) के बीच अंतर को समझता हूं, लेकिन मैं वास्तव में किसी भी कारण से नहीं सोच सकता कि मैं एक नई परियोजना के लिए आगे बढ़ने वाले एमवीसी मॉडल का चयन क्यों नहीं करूंगा।

अपने अनुभव में कोई कारण/बार जब एक MVC वास्तुकला उपयुक्त नहीं होगा, या किसी भी कारणों से आप एक BLL/DAL वास्तुकला बजाय चुनते हैं वहाँ है?

Answer 1

कारकों में से एक आपके वेब एप्लिकेशन की स्थिति हो सकती है। यदि यह एक मूल वेब एप्लिकेशन है जो क्लाइंट साइड सत्यापन जैसे कुछ जावास्क्रिप्ट हुक के साथ सर्वर से सब कुछ प्राप्त करता है, तो रेल प्रकार एमवीसी वास्तव में बहुत अच्छा है। मैं एएसपी.नेट पर एमवीसी से परिचित नहीं हूं, लेकिन मैंने सुना है कि यह रेल के समान है।

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

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

Answer 2

मुझे नहीं लगता कि आपके विकल्प परस्पर अनन्य हैं। आप अपने मॉडल तर्क के लिए बीएलएल/डीएएल का उपयोग करते समय पूरी तरह से एमवीसी का उपयोग कर सकते हैं।

आप के रूप में आप पसंद करते हैं MVC के M हिस्सा लागू कर सकते हैं, इस बारे में कोई प्रतिबंध नहीं है। बीएलएल और डीएएल का उपयोग करना एक वैध विकल्प होगा।

Answer 3

मेरे लिए? एमवीसी का उपयोग नहीं करने का एकमात्र कारण यह है कि जिस एप्लिकेशन पर मैं काम कर रहा हूं वह वेब फॉर्मों में पहले ही शुरू हो चुका था। मैं स्क्रैप/पुनः लिखने का बड़ा समर्थक नहीं हूं, लेकिन एमवीसी में मैं जो भी नया करता हूं वह है।

Answer 4

मैं केवल से मिलकर वास्तव में छोटा परियोजनाओं पर MVC उपयोग नहीं करते ~ 1-2 फ़ाइलें और ~ कोड की 10-20 लाइनों। और वे शायद ही कभी कुछ बड़ा हो जाएंगे।

लेकिन अगर वे करेंगे, तो यह उन्हें एक एमवीसी में पुनर्गठन करने का समय होगा।

Answer 5

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

Answer 6

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

Answer 7

मैं केवल एमवीसी पैटर्न का उपयोग नहीं करता जब मेरे पास एमवीपी के साथ एक मौजूदा डेस्कटॉप एप्लिकेशन बनाया गया है और मुझे इसे एक वेब वातावरण में परिवर्तित करना है। ऐसा इसलिए है क्योंकि मैंने पहले से ही प्रस्तुतकर्ता के लिए तर्क लिखा है।
किसी भी अन्य मामले में मैं एमवीसी का उपयोग करूंगा।

Answer 8

Life above the service tier सुझाव देता है कि आपको एमवीसी पैटर्न का उपयोग ऐसे तरीके से करना चाहिए जो सोफिया सिद्धांतों का पालन करता है, और एमवीसी परिवर्णी शब्द के पीछे छिपाने वाले "फ्रंट कंट्रोलर" प्रकार के ढांचे के लिए बाहर निकलना चाहिए। (या, आप अभी भी उनका उपयोग कर सकते हैं, लेकिन कम से कम लेख पढ़ें, मतभेदों को समझें और बुद्धिमानी से चुनें)।

Answer 9

सरल उत्तर है, नहीं।

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

Answer 10

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

यदि इसकी एक छोटी सी साइट, या बहुत कम पेज/नियंत्रण, तो मैं सख्त डिजाइन पैटर्न पर चिपकने से बचूंगा। लेकिन यह सिर्फ मेरी वरीयता है।

एक पोस्टर के रूप में, आपको किसी भी मौजूदा अनुप्रयोगों और आपके विकास टीम कौशल/अनुभव की स्थिति पर भी विचार करना होगा।

Answer 11

कुछ पन्नों के लिए

, MVC एक छोटे से overkill हो सकता है:

• छप पृष्ठों
• लैंडिंग पृष्ठों
• विपणन पृष्ठों का उपयोग करने के बाद
• एक बंद के
फेंक दिया जा रहा है

एक सुंदर एमवीसी आर्किटेक्चर बनाने के लिए लपेटना आसान है, जब एक छोटा पृष्ठ, संक्षेप में लिखा गया है, ठीक हो सकता है से परिस्थितियों में

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

Answer 12

आप

http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should-i-use-it.aspx

और http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080017 निम्नलिखित का उल्लेख कर सकते "undisputable तथ्य" का संदर्भ लें।