मेरे एमवीसी अनुप्रयोग के लिए एक सेवा परत बनाना?

Question

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

ऐसा लगता है कि व्यवसाय तर्क में वास्तव में कोई जगह नहीं है ... इसलिए मैं सोच रहा हूं कि सेवाओं के लिए एक और परत उपयुक्त होगी। मुझे यकीन नहीं है कि इस परत को कहां रखा जाए, या सेवाओं को कैसे बनाया जाए - क्या इसे "सेवाओं" नामक एक वर्ग होना चाहिए जिसमें कार्यों का एक गुच्छा शामिल है? मैं एमवीसी के लिए थोड़ा नया हूं, इसलिए कोई भी पढ़ने की सामग्री, नमूने, या सामान्य नवागंतुक की तरह युक्तियाँ बहुत ही शानदार होंगी।

Answer 1

मैं आमतौर पर एएसपी.नेट एमवीसी अनुप्रयोग विकसित करते समय एक सेवा परत का उपयोग करता हूं। यह Service Layer Pattern के समान है कि मार्टिन फाउलर एंटरप्राइज़ एप्लिकेशन आर्किटेक्चर के पैटर्न पर चर्चा करता है। यह आपके व्यापार तर्क को समाहित करता है और नियंत्रकों को बहुत पतला बना देता है। मूल रूप से नियंत्रक डोमेन मॉडल प्राप्त करने के लिए सेवा परत का उपयोग करते हैं जिन्हें बाद में मॉडल में परिवर्तित किया जाता है। मैं लेनदेन को संभालने के लिए Unit of Work Design Pattern का उपयोग करता हूं और Repository Design Pattern आसान इकाई परीक्षण के लिए डेटा एक्सेस परत को समाहित करने और ओआरएम को आसानी से स्वैप करने में सक्षम होने के लिए भी उपयोग करता हूं। यह आंकड़ा सामान्य परतों को दिखाता है जो मैं एक एमवीसी अनुप्रयोग में उपयोग करता हूं।

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

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

Answer 2

लगता है जैसे आप एक भंडार पैटर्न की तरह कुछ के बाद होंगे। आप इसके बारे में यहाँ पढ़ सकते हैं:

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

यहाँ इस उत्तर भी मदद मिल सकती:

Best Repository Pattern for ASP.NET MVC

Answer 3

MSDN सर्वोत्तम प्रथाओं से article पर एक नजर डालें।

लेख में आवेदन का स्रोत कोड here पाया जा सकता है।

Answer 4

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

public class MyService : IMyService 
{ 
    IFirstDependency _firstService; 
    ISecondDependency _secondService; 

    public MyService(IFirstDependency firstService, ISecondDependency secondService) 
    { 
    } 

    public Result DoStuf(InputDTO) 
    { 
     // some important logic   
    } 
} 

तो फिर आप अपने नियंत्रक से इन सेवा का उपभोग: तो फिर आपकी सेवा वर्गों की तरह लग सकता है। पूर्ण उदाहरण के लिए here देखें।

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

Answer 5

“Business logic should be in a service, not in a model”? से हवाला देते हुए:

एक एमवीपी/MVC/MVVM/एम वी में * वास्तुकला, सेवाओं बिल्कुल भी मौजूद नहीं है। या यदि वे करते हैं, तो शब्द का प्रयोग किसी भी जेनेरिक ऑब्जेक्ट को संदर्भित करने के लिए किया जाता है जिसे नियंत्रक में इंजेक्शन दिया जा सकता है या मॉडल को देखा जा सकता है। व्यापार तर्क आपके मॉडल में है। यदि आप जटिल परिचालनों को व्यवस्थित करने के लिए "सेवा ऑब्जेक्ट्स" बनाना चाहते हैं, तो इसे कार्यान्वयन विवरण के रूप में देखा जाता है। बहुत से लोग, दुख की बात है, इस तरह एमवीसी को लागू करते हैं, लेकिन इसे एंटी-पैटर्न (एनीमिक डोमेन मॉडल) माना जाता है क्योंकि मॉडल स्वयं कुछ भी नहीं करता है, यह यूआई के लिए गुणों का एक गुच्छा है।

कुछ लोग गलती से सोचते हैं कि 100-लाइन नियंत्रक विधि लेना और किसी भी सेवा में इसे किसी भी तरह से बेहतर बनाना एक बेहतर वास्तुकला बनाता है। यह वास्तव में नहीं करता है; यह सब एक और, अप्रत्यक्ष की अनावश्यक परत जोड़ता है। व्यावहारिक रूप से बोलते हुए, नियंत्रक अभी भी काम कर रहा है, यह सिर्फ एक खराब नामित "सहायक" ऑब्जेक्ट के माध्यम से ऐसा कर रहा है। मैं एनीमिक डोमेन मॉडल को उपयोगी में बदलने के तरीके के स्पष्ट उदाहरण के लिए जिमी बोगर्ड की Wicked Domain Models प्रस्तुति की अत्यधिक अनुशंसा करता हूं। इसमें आपके द्वारा उजागर किए जा रहे मॉडल की सावधानीपूर्वक जांच शामिल है और कौन से ऑपरेशन वास्तव में व्यावसायिक संदर्भ में मान्य हैं।