एक सेवा परत और ASP.NET MVC 2

Question

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

वर्तमान में, मैं भंडार पैटर्न, मॉडल, नियंत्रकों, डेटा एनोटेशन, आदि को समझने लेकिन वहाँ एक बात यह है कि मुझे पूरी तरह से पर्याप्त समझ से बना रहा एक संदर्भ आवेदन पर काम शुरू करने के लिए है।

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

मैंने यह पोस्ट भी पढ़ा: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx और ऐसा लगता है कि अगर आप अपना सत्यापन करने के लिए डेटा एनोटेशन का उपयोग कर रहे हैं, तो यह अनावश्यक लगता है।

मैं प्रदर्शनों, पोस्ट, आदि के लिए देखा है, लेकिन मैं कुछ भी है कि बस पैटर्न बताते हैं और मुझे सम्मोहक सबूत इसका इस्तेमाल करने देता है खोजने के लिए प्रतीत नहीं कर सकते हैं।

किसी एक 2 ग्रेड (ठीक है, शायद 5 वीं ग्रेड) कारण इस पद्धति का उपयोग करने के साथ मुझे प्रदान करें कर सकते हैं, मैं अगर मैं नहीं करते हैं, और मैं क्या हासिल करता है, तो मैं क्या खो देगा क्या?

Answer 1

एक एमवीसी पैटर्न में आपके पास 3 खिलाड़ियों के बीच जिम्मेदारियां अलग-अलग हैं: मॉडल, व्यू और कंट्रोलर।

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

मॉडल आमतौर पर डेटाबेस द्वारा समर्थित होता है ताकि आपके पास कुछ डीएओ इसका उपयोग कर सकें। आपका व्यवसाय कुछ करता है ... अच्छा ... व्यवसाय और स्टोर या डेटाबेस से डेटा/डेटा पुनर्प्राप्त करता है।

लेकिन डीएओ का समन्वय कौन करता है? नियंत्रक? नहीं! मॉडल चाहिए।

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

अगर आप इसे इस्तेमाल नहीं करते तो क्या होगा?

आप व्यापार तर्क कहीं डाल करने के लिए होगा और शिकार आमतौर पर नियंत्रक है।

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

ठीक है, आपको नियंत्रक को फिर से लिखना होगा और तर्क क्लाइंट अज्ञेयवादी बनाना होगा। लेकिन सेवा परत के साथ आपके पास पहले से ही है। आपको चीजों को फिर से लिखने की जरूरत नहीं है।

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

Answer 2

मुझे कहना है कि मैं ऊपर के साथ डीपीबी से सहमत हूं, रैपर यानी सेवा परत पुन: प्रयोज्य, नकली है, मैं वर्तमान में इस ऐप के अंदर इस परत को शामिल करने की प्रक्रिया में हूं ... यहां कुछ मुद्दे/आवश्यकताएं हैं मैं सोच रहा हूं (बहुत जल्दी: पी) जो आपके लिए मदद से दूर हो सकता है ...
1. एकाधिक पोर्टल (जैसे ब्लॉगर्स पोर्टल, क्लाइंट पोर्टल, आंतरिक पोर्टल) जिन्हें कई अलग-अलग उपयोगकर्ताओं द्वारा एक्सेस किया जाना आवश्यक है। वे सभी अलग-अलग एएसपी.नेट एमवीसी अनुप्रयोगों (एक महत्वपूर्ण आवश्यकता) होना चाहिए
2. ऐप्स के भीतर स्वयं डेटाबेस में कुछ कॉल समान होंगे, तरीके और डेटा को रिपोजिटरी परत से संभाला जा सकता है। बिना किसी संदेह के प्रत्येक मॉड्यूल/पोर्टल से कुछ नियंत्रक एक ही कॉल के बिल्कुल या अधिभारित संस्करण बनाएंगे, इसलिए सेवा परत (इंटरफेस के लिए कोड) की एक संभावित आवश्यकता है जिसे मैं एक अलग श्रेणी प्रोजेक्ट में संकलित कर दूंगा।
3. अगर मैं अपनी सेवा परत के लिए एक अलग श्रेणी प्रोजेक्ट बनाता हूं तो मुझे डेटा लेयर के लिए ऐसा करने की आवश्यकता हो सकती है या इसे सेवा परत के साथ संयोजित कर सकते हैं और मॉडल को वेब प्रोजेक्ट से ही दूर रख सकते हैं। कम से कम इस तरह से मेरा प्रोजेक्ट बढ़ता है, मैं डेटा एक्सेस लेयर (यानी लिंक्टोस्क्ल -> एनएचबर्ननेट) निकाल सकता हूं, या कोई टीम सदस्य किसी भी अन्य प्रोजेक्ट में किसी भी कोड पर काम किए बिना काम कर सकता है। नकारात्मकता हो सकती है कि वे सब कुछ उड़ा सकते हैं ...