MVC: एक मॉडल और सेवा के बीच क्या अंतर है?


15

क्यों कुछ रूपरेखाओं में तर्क परत को "मॉडल" कहा जाता है जबकि कुछ में इसे "सेवा" कहा जाता है। क्या वे एक-दूसरे से अलग हैं या सिर्फ सम्मेलनों के नामकरण से अलग हैं?


अद्यतन १

कारण मैं पूछ रहा हूं क्योंकि Zend फ्रेमवर्क, एक शास्त्रीय MVC फ्रेमवर्क है, हर कोई मॉडल की अवधारणा का उपयोग करता है। अब मैं AngularJS सीख रहा हूं और ऐसा लगता है कि मॉडल शब्द गायब हो गया और इसे शब्द सेवा द्वारा बदल दिया गया।

मैंने जो देखा वह यह है कि एक सेवा एक सिंगलटन की तरह अधिक है जिसे बार-बार पुन: उपयोग किया जा सकता है (उदाहरण: एक आरईएसटी क्लाइंट) जबकि एक मॉडल एमवीसी पैटर्न में नियंत्रक से आने वाले डेटा जोड़तोड़ से अधिक संबंधित है।


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

शेक्सपियर के प्रतिमान: एक नाम में, किसी अन्य नाम से एक गुलाब अभी भी एक गुलाब है। आपके एप्लिकेशन मॉडल को एक सेवा के रूप में अच्छी तरह से लागू किया जा सकता है।
jwenting

जवाबों:


22

मॉडल: फ़ील्ड जो ऑब्जेक्ट से संबंधित हैं, वे विधियाँ जो ऑब्जेक्ट से डेटा सेट / सेट करने में मदद करती हैं (एक फुलनाम एक्सेसर जो पहले + दूसरा नाम देता है)

सेवा: एक या एक से अधिक मॉडलों के साथ संचालन करने के तरीके, 'कार्य की इकाई', लेनदेन आदि देखें ...


कर्मचारी :: बनाने के लिए बस डेटा का एक सेट लेना चाहिए, यदि आवश्यक हो तो मॉडल सत्यापन करें, और एक कर्मचारी ऑब्जेक्ट लौटाएं।

कर्मचारी सेवा: किराया कर्मचारी कर्मचारी बना सकते हैं, उन्हें एक स्वागत योग्य ईमेल भेज सकते हैं, एक मेलबॉक्स बना सकते हैं, उन्हें एक सैंडविच बना सकते हैं, आदि ... यह डेटा के सेट, या परिणाम कोड, आदि को वापस कर सकता है ...


यह मान्यता को भी प्रभावित कर सकता है:

मॉडल सत्यापन: कर्मचारी के पास एक आईडी, पहला और अंतिम नाम और जन्मदिन होना चाहिए

सेवा मान्यता: बारटेंडर पद के लिए कर्मचारी 21 या अधिक होना चाहिए, और एक प्रबंधक द्वारा अनुमोदित होना चाहिए।


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

3

मेरे अनुभव के अनुसार, MVC डिजाइन पैटर्न के भीतर मॉडल परत डेटा हेरफेर (POJOs, DAO, SQL, JDBC, और इतने पर सभी तरह से) के साथ शामिल हर सॉफ्टवेयर घटक को संदर्भित करता है।

जबकि सेवा परत वास्तव में MVC के अतिरिक्त है:

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

आखिरकार, आप स्थैतिक तरीकों से अपने गंदे कोड को एक सार्थक नाम, मापदंडों और आगे के साथ शामिल कर सकते हैं, जो एक सिंथेटिक नियंत्रक परत का परिणाम होगा।

इस लिंक पर एक नज़र डालें:

/programming/2762978/the-purpose-of-a-service-layer-and-asp-net-mvc-2


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

2

संरचनात्मक रूप से ये आधार वर्ग समान हैं, हालाँकि इनका उपयोग एमवीसीएससी कार्यान्वयन की सेवा और मॉडल स्तरों की एक अलग चिंताओं को वर्गीकृत करने के लिए किया जाता है।

Service:- A concrete service class defines the API of an external Service.

Model :- Defines the API of the applications data model.

इसलिए, जब आधार वर्ग एक जैसे होते हैं, तो इन आधार वर्गों का विस्तार करके बनाई गई ठोस कक्षाएं दो पूरी तरह से अलग उद्देश्यों की पूर्ति करती हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.