नेट एमवीसी आर्किटेक्चर इतनी जटिल बनाम रेल क्यों है?

Question

नोट: यह एक्स पर एक पोस्ट से बहुत दूर x से बेहतर है। खुश नहीं वहाँ जाओ।

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

नेट एमवीसी में हमें चिंताएं अलग करने, डेटा एक्सेस, बिजनेस लॉजिक और व्यू को संभालने के लिए अलग-अलग परियोजनाएं बनाने के लिए प्रोत्साहित किया जाता है, हमें यह भी बताया जाता है कि हमें कन्वर्ट करना चाहिए दृश्य डेटा को हिट करने से पहले हमारे डेटा ऑब्जेक्ट्स को देखने के लिए

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

तो क्यों एक ढांचा में यह पद्धति स्वीकार्य है और दूसरे में यह गलत समझा जाता है और हम सभी अधिक कोड लिखते हैं और अधिक फाइलें बनाते हैं।

नोट: मैं कोई रेल विशेषज्ञ नहीं हूं और मैं वास्तव में तुलना करने की कोशिश नहीं कर रहा हूं जो x से बेहतर है, मैं 2 ढांचे के उच्च स्तरीय वास्तुकला को देख रहा हूं और यह काम कर रहा हूं कि यह एक में स्वीकार्य है लेकिन दूसरे नहीं ।

Answer 1

यह इस बात पर निर्भर करता है कि आप किस प्रकार के एप्लिकेशन को विकसित कर रहे हैं और आप इसे कितना बढ़ने की उम्मीद करते हैं।

छोटे अनुप्रयोगों के लिए अलग-अलग दृश्य और डोमेन मॉडल के साथ जटिलताओं की जटिलता की आवश्यकता नहीं है (लेकिन आप अलग दृश्य मॉडल और इकाइयों का उपयोग करना चाह सकते हैं: http://blog.gauffin.org/2011/07/three-reasons-to-why-you-should-use-view-models/)।

सीआरयूडी अनुप्रयोगों के लिए आपको रिपोजिटरी पैटर्न जैसे अबास्ट्रक्शन में अपना डेटा एक्सेस लपेटना नहीं है।

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

मैं कारण है कि मैं कपोल-कल्पना का उपयोग करें के बारे में एक छोटे से ब्लॉग प्रविष्टि लिखा है: http://blog.gauffin.org/2013/01/data-layer-the-right-way/

और क्यों कैप्सूलीकरण महत्वपूर्ण है: http://blog.gauffin.org/2012/06/protect-your-data/