.NET MVC प्रोजेक्ट आर्किटेक्चर / लेयरिंग

Question

मध्य-बड़े पैमाने पर MVC वेब एप्लिकेशन के लिए आर्किटेक्चर की योजना बनाते समय आप परतों को कैसे लागू कर सकते हैं जितना संभव हो उतना आसान और परीक्षण करना आसान है? (मूल रूप से सर्वोत्तम प्रथाओं का पालन करें) मान लें कि मैं अपने डेटा एक्सेस के रूप में पहले कोड का उपयोग कर रहा हूं।

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

यह भी कि व्यवसाय के विपरीत आवेदन तर्क क्या होगा - मैं सत्र / उपयोगकर्ता इनपुट सत्यापन जैसी चीजों का अनुमान लगा रहा हूं?

इसलिए, उदाहरण के लिए, एक कार नियंत्रक एक एक्शन / व्यू रिजल्ट लौटा सकता है जो टाइप और बेस्ट mpg द्वारा फ़िल्टर की गई शीर्ष दस कारों को सूचीबद्ध करता है। तो ICarRepositoryमान लें कि मेरे पास मेरे कंट्रोलर (रिपॉजिटरी पैटर्न / DI का उपयोग करके) में एक 'carRepo' है, मैं अपनी कारों को एक्शन विधि पैरामीटर से फ़िल्टर करता हूँ जैसेvar cars = carRepo.getCarsByType("hatchback");

इसलिए मैंने एक रिपॉजिटरी का उपयोग करके अपने कंट्रोलर से डेटा एक्सेस ज्ञान को रखा है, अब डोमेन लॉजिक का उपयोग करके कंट्रोलर के बिजनेस लॉजिक को बनाए रखने के लिए - var result = new MpgCalculator (Cars); - मान लें कि मुझे कैलकुलेटर वर्ग की आवश्यकता है क्योंकि यह DB से सर्वश्रेष्ठ लोडिंग / फ़िल्टरिंग संस्थाओं से अधिक, सर्वोत्तम ईंधन दक्षता की गणना करने के लिए अतिरिक्त तर्क करने की आवश्यकता है। इसलिए अब मेरे पास यह देखने के लिए एक डेटा सेट है कि रेंडर करने के लिए डेटा एक्सेस लेयर और डोमेन विशिष्ट ऑब्जेक्ट को प्राप्त करने के लिए एक रिपॉजिटरी का उपयोग करने के लिए उस डेटा पर व्यापार संबंधी कार्यों को संसाधित करने और निष्पादित करने के लिए मेरे पास एक डेटा सेट है।

क्या मैं यहाँ गलतियाँ कर रहा हूँ? क्या हमें अभी भी रिपॉजिटरी पैटर्न का उपयोग करने की आवश्यकता है या क्या मैं ओआरएम और परीक्षण को समाप्त करने के लिए इंटरफ़ेस के खिलाफ कोड कर सकता हूं? इस विषय पर, जैसा कि मेरे ठोस डेटा एक्सेस क्लैसे (एस) dbcontext डेटा लेयर में हैं, क्या इंटरफ़ेस की परिभाषाएँ डोमेन / व्यावसायिक परत में जानी चाहिए जिसका अर्थ है कि यदि डेटा एक्सेस तकनीक कभी बदली जाती है, तो मेरी अन्य परतें प्रभावित नहीं होती हैं?

इस तरह से मैंने जो भी अध्ययन किया है उससे मेरी संरचना इस तरह दिखती है:

MVC इंटरनेट अनुप्रयोग -> मानक इंटरनेट परियोजना - यहाँ मॉडल ViewModels हैं

डोमेन / व्यावसायिक परत -> व्यवसाय विशिष्ट वर्ग / मॉडल जो नियंत्रकों का उपयोग प्रासंगिक विचारों पर गुजरने से पहले डेटा परत से डोमेन संस्थाओं को संसाधित करने के लिए कर सकते हैं

रिपॉजिटरी अमूर्त आवश्यक है? -> मैं इस पर बहुत बहस सुनता हूं, खासकर जब ओआरएम का उपयोग कर रहा हो

डेटा परत -> इकाई वर्ग (कार, वैन, मोटरसाइकिल), DbContext - कंक्रीट डेटा एक्सेस प्रौद्योगिकी परत

Answer 1

आपको अपने प्रश्न में बहुत सारे घूमने वाले हिस्से मिले हैं, बहुत सी अवधारणाओं को छूते हुए, लेकिन यहाँ मेरी बुनियादी सलाह है कि जब मध्य-से-बड़े पैमाने पर एमवीसी एप्लिकेशन के बारे में सोचा जाए तो:

प्रस्तुति <---> व्यापार तर्क <---> डेटा एक्सेस

सबसे पहले, ऐप को "एमवीसी एप्लिकेशन" के रूप में नहीं सोचना सबसे अच्छा है । यह एक ऐसा एप्लिकेशन है जो एमवीसी पैटर्न को अपनी प्रस्तुति घटक के रूप में उपयोग करता है। इसके बारे में इस तरह से सोचने से आपको अपने व्यापार तर्क की चिंताओं को अपनी प्रस्तुति चिंताओं से अलग करने में मदद मिलेगी । शायद MVC संरचना में डेटाबेस के उपयोग के लिए सब कुछ ढेर करने के लिए छोटे अनुप्रयोगों के लिए ठीक है, लेकिन यह जल्दी से एक मध्य-से-बड़े आवेदन के लिए अस्थिर हो जाएगा।

MVC (प्रस्तुति)

आपके ऐप में, ASP.NET MVC घटक को प्रदर्शन उद्देश्यों (मॉडल) के लिए व्यावसायिक डेटा को बदलने, उपयोगकर्ता इंटरफ़ेस (दृश्य), और संचार मुद्दों जैसे कि रूटिंग, प्रमाणीकरण, प्राधिकरण, अनुरोध सत्यापन, प्रतिक्रिया से निपटने, और जैसे (नियंत्रकों)। यदि आपके पास कोड है जो कुछ और करता है, तो यह MVC घटक में नहीं है ।

रिपोजिटरी / ओआरएम (डेटा एक्सेस)

आपके ऐप में भी, डेटा एक्सेस लेयर का संबंध निरंतर डेटा प्राप्त करने और संग्रहीत करने से होना चाहिए। आमतौर पर यह एक संबंधपरक डेटाबेस के रूप में है, लेकिन कई अन्य तरीके हैं जिनसे डेटा को बनाए रखा जा सकता है। यदि आपके पास ऐसा कोड है जो लगातार डेटा नहीं पढ़ रहा है या संग्रहीत नहीं कर रहा है, तो यह डेटा लेयर में नहीं है । मैंने एसओ पर पहले ओआरएम / रिपॉजिटरी चर्चा पर अपने विचार साझा किए थे , लेकिन फिर से सोचने के लिए, मैं कई कारणों से ओआरएम को रिपोजिटरी के रूप में एक ही चीज नहीं मानता।

व्यापार का तर्क

तो अब आपके पास आपकी प्रेजेंटेशन लेयर (MVC), और आपकी डेटा लेयर (रिपॉजिटरी या ORM) है ... बाकी सब आपकी बिजनेस लॉजिक लेयर (BLL) है। आपके सभी कोड जो यह तय करते हैं कि कौन सा डेटा पुनर्प्राप्त करना है, या जटिल गणना करता है, या व्यावसायिक निर्णय करता है, यहां होना चाहिए। मैं आमतौर पर अपने व्यावसायिक तर्क को 'सेवाओं' के रूप में व्यवस्थित करता हूं, जिसे मेरी प्रस्तुति परत अनुरोधित कार्य करने के लिए कह सकती है। मेरे सभी डोमेन मॉडल यहां मौजूद हैं।

आपका दृष्टिकोण

यह वह जगह है जहां आपका दृष्टिकोण मेरे लिए थोड़ा टूट जाता है। आप अपने MVC कंट्रोलर का वर्णन उस जगह के रूप में करें जहाँ से आपको रिपॉजिटरी का डेटा मिलेगा, और MPGCalculator को कॉल करके कुछ काम करने के लिए कहा जाएगा, इत्यादि, मेरा कंट्रोलर इस बारे में कुछ नहीं करेगा, लेकिन इसके बजाय यह सब एक सेवा को सौंप देगा। बीएलएल में।

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

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

Comments

हाय एरिक, उत्कृष्ट उत्तर - रिपॉजिटरी के संबंध में, मुझे लगता है कि ठोस वर्ग डेटा एक्सेस लेयर और 'ICarRepository' आदि में बिज़नेस / सर्विस लेयर में रहेंगे? तब मैं अपने कंट्रोलर को सेवाएं दे सकता था जिसमें आवश्यकताओं के आधार पर 1 या अधिक रिपॉजिटरी हो सकती हैं?

— माइकल हार्पर

@MichaelHarper हाँ, यह इसके बारे में जाने का एक अच्छा तरीका लगता है।

— एरिक किंग

जबकि प्रमाणीकरण एक नियंत्रक चिंता है (अलग-अलग यूआई अलग-अलग प्रमाणित करते हैं) मैं कहता हूं कि प्राधिकरण व्यावसायिक तर्क है और व्यावसायिक परत में है। क्या आप सहमत हैं?

— टॉम

@tom हां, आपके पास एक अच्छा बिंदु है। मैं साधारण प्राधिकरण के बारे में सोच रहा था क्योंकि उपयोगकर्ता के पास इस मार्ग तक पहुंच है , लेकिन इसके अलावा भी बहुत कुछ हो सकता है। "बहुत अधिक यह" भाग व्यवसाय की परत में है।

— एरिक किंग

@ हंटरनरेल्सन यदि आप किसी व्यूमोडल में मैपिंग कर रहे हैं, तो मैपिंग जहां दृश्य परत में है, वहां होनी चाहिए। यह कहीं और मतलब नहीं होगा।

— एरिक किंग

Answer 2

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

विचार का एक विद्यालय है कि यदि आपके पास कोई भी होने जा रहा है, तो आपको अपने एमवीसी आवेदन में अपने डोमेन परत का पूरा अमूर्त होना चाहिए। व्यक्तिगत रूप से, एक उद्यम अनुप्रयोग में ऐसा करने का विचार मुझे गंभीर मानसिक पीड़ा देता है।

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

Comments

उत्तर के लिए धन्यवाद विलियम consider मैं अपनी व्यावसायिक वस्तुओं / तर्क और डोमेन संस्थाओं को 'मॉडल' मानूंगा, जिसका उपयोग उपयोगकर्ता उपयोगकर्ता के कार्यों को देखने के लिए करता है और व्यू मॉडल को विशिष्ट मॉडल के रूप में देखता है जिसमें मॉडल आदि के समूह हो सकते हैं

— माइकल हार्पर