"व्यावसायिक तर्क परत" MVC अनुप्रयोग में कहाँ फिट होती है?


86

सबसे पहले, किसी को भी चीखने से पहले, मुझे एक साधारण शीर्षक में इसे संक्षेप में बताने का कठिन समय था। एक अन्य शीर्षक "डोमेन मॉडल और एमवीसी मॉडल के बीच अंतर क्या है?" या "एक मॉडल क्या है?"

वैचारिक रूप से, मैं एक मॉडल को विचारों और नियंत्रक द्वारा उपयोग किया जाने वाला डेटा समझता हूं। इससे परे, मॉडल को बनाने के बारे में अलग-अलग राय है। एक डोमेन मॉडल, बनाम एक ऐप मॉडल, बनाम एक दृश्य मॉडल, बनाम एक सेवा मॉडल, आदि क्या है।

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

एक सरल उदाहरण लेते हैं। खाता नियंत्रक जो MVC डिफ़ॉल्ट प्रोजेक्ट के साथ शामिल है। मैंने कई राय पढ़ी हैं कि इसमें शामिल खाता कोड खराब डिज़ाइन का है, SRP, आदि का उल्लंघन करता है। आदि आदि। यदि कोई MVC एप्लिकेशन के लिए "उचित" सदस्यता मॉडल डिज़ाइन करता है, तो वह क्या होगा?

आप मॉडल से ASP.NET सेवाओं (सदस्यता प्रदाता, भूमिका प्रदाता, आदि) को अलग कैसे करेंगे? या आप बिलकुल करेंगे?

जिस तरह से मैं इसे देखता हूं, मॉडल को "शुद्ध" होना चाहिए, शायद सत्यापन तर्क के साथ .. लेकिन व्यावसायिक नियमों (सत्यापन के अलावा) से अलग होना चाहिए। उदाहरण के लिए, मान लें कि आपके पास एक व्यावसायिक नियम है जो कहता है कि नया खाता बनाते समय किसी को ईमेल किया जाना चाहिए। यह वास्तव में मेरे विचार में मॉडल से संबंधित नहीं है। तो इसका संबंध कहां से है?

किसी को भी इस मुद्दे पर कोई प्रकाश डाला परवाह है?


1
इसलिए आपको चार अलग-अलग प्रश्न पूछने चाहिए।
जॉन फैरेल 19

3
कीवर्ड "लगभग" है। यह वास्तव में एक ही सवाल है, शायद प्राथमिक प्रश्न का वर्णन करने के लिए उपयोग किए जाने वाले उपशमन के साथ।
एरिक फनकेनबस

3
मॉडल - व्यू - नियंत्रक। क्या रिपॉजिटरी / बीएल व्यू है? क्या यह नियंत्रक है? नहीं, क्या बचा है :)? यह MVC है, MSVC नहीं, MRVC नहीं, MBLVC नहीं। सिर्फ तीन परतें हैं। इसलिए भंडार मॉडल का हिस्सा है, बीएल मॉडल का हिस्सा है। और आप अतिरिक्त अलगाव कर सकते हैं, लेकिन यह मॉडल परत के अंदर किया जाता है।
लुकलेड

3
@LukeLed, @bslm - वास्तव में नहीं। MVC यह नहीं कहता कि नियंत्रक या मॉडल के साथ अन्य परतें नहीं हो सकती हैं।
जॉन फैरेल

3
@LukLed - असहमत - MVC केवल एक प्रस्तुति परत पैटर्न है। इसका कोई प्रभाव नहीं पड़ता है कि आप अपनी अन्य परतों जैसे बीएलएल और डीएएल की संरचना कैसे करते हैं।
कोरी हाउस

जवाबों:


69

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

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

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

क्रेडिट कार्ड के साथ काम करने के दौरान केस - मुझे भुगतान संसाधित करते समय एक cvv की आवश्यकता होती है, लेकिन मैं cvv को संग्रहीत नहीं कर सकता (ऐसा करने के लिए यह $ 50,000 का जुर्माना है)। लेकिन, मैं यह भी चाहता हूं कि आप अपने क्रेडिट कार्ड को संपादित करने में सक्षम हों - पते, नाम, या समाप्ति की तारीख। लेकिन आप मुझे इसे संपादित करते समय संख्या या cvv नहीं देने जा रहे हैं, और मैं निश्चित रूप से पृष्ठ पर सादे पाठ में आपके क्रेडिट कार्ड नंबर को डालने नहीं जा रहा हूं। मेरे डोमेन में नए क्रेडिट कार्ड सहेजने के लिए ये मूल्य आवश्यक हैं क्योंकि आप उन्हें मुझे देते हैं, लेकिन मेरे संपादन मॉडल में कार्ड नंबर या cvv शामिल नहीं है।

इतनी सारी परतों के लिए एक और लाभ यह है कि यदि सही ढंग से आर्किटेक्चर किया गया है, तो आप स्ट्रक्चरमैप या किसी अन्य आईओसी कंटेनर का उपयोग कर सकते हैं और अपने आवेदन को प्रभावित किए बिना टुकड़ों को स्वैप कर सकते हैं।

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

<% if (!String.IsNullOrEmpty(Model.SomeObject.SomeProperty) && 
    Model.SomeObject.SomeInt == 3 && ...) { %>

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


हमारे उद्यम एमवीसी एप्लिकेशन में मेरे पास जो कुछ है, उसके बारे में बस एक दर्पण। एक एन-टीयर वास्तुकला। एमवीसी ऐप केवल एन-टियर क्षेत्रों में व्यापारिक वस्तुओं और सेवाओं के साथ बातचीत करता है।
एड डेगेंन

ज्यादातर यहाँ वही है। परिभाषाओं, मॉडल, व्यूमॉडल, डीएएल, आदि के लिए अलग-अलग परियोजनाएं। केवल अंतर यह है कि मेरी डीएएल में रिपोर्ट या कस्टम ग्राहक के विचारों के लिए जटिल डेटा के वितरण का अनुकूलन करने के लिए वेब के लिए डेटा को समतल करने के लिए तर्क शामिल हैं। मैं अब वेब में फार्म और एज़्योर बादलों के साथ लुक-अप टेबल आदि के लिए एप्लिकेशन कैश में चीजों को रखने से कतराता हूं।
रॉबर्ट अचमन

1
@ जोश, यह उपयोगी होगा यदि आप अपने नमूना प्रोजेक्ट का स्क्रीन शॉट दिखा सकते हैं?
शाइजुत

यदि आपकी परियोजना में डेटाबेस नहीं है, तो @Josh। यह सेवा संदर्भों के साथ सहभागिता करता है। सभी डोमेन कक्षाएं और विधि इन संदर्भों से आती हैं। क्या यह परिदृश्य स्तरित संरचना के लिए फिट है?
user6395764

17

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

मेरा मानना ​​है कि ऊपर बताए गए, व्यापक रूप से स्वीकृत वास्तुकला के कारण भ्रम मौजूद है, जो "एनीमिक डोमेन मॉडल" (कथित) -ant पैटर्न का उपयोग करता है। मैं एनीमिक डेटा मॉडल के "एंटी-पैटर्ननेस" के बारे में बहुत अधिक विवरणों में नहीं जाऊंगा (आप यहां चीजों को समझाने के लिए मेरा प्रयास देख सकते हैं (जावा-आधारित, लेकिन किसी भी भाषा के लिए प्रासंगिक)। लेकिन संक्षेप में, इसका मतलब है कि हमारा मॉडल केवल डेटा रखता है, और सेवाओं / प्रबंधकों में व्यावसायिक तर्क रखा जाता है।

लेकिन मान लेते हैं कि हमारे पास डोमेन संचालित आर्किटेक्चर है , और हमारे डोमेन ऑब्जेक्ट्स वे हैं जो वे होने की उम्मीद करते हैं - राज्य और व्यावसायिक तर्क दोनों। और इस डोमेन संचालित परिप्रेक्ष्य में चीजें जगह में आती हैं:

  • दृश्य UI है
  • नियंत्रक UI के इनपुट को इकट्ठा करता है, मॉडल पर तरीकों को आमंत्रित करता है, और UI पर प्रतिक्रिया भेजता है
  • मॉडल हमारे व्यावसायिक घटक हैं - डेटा को पकड़े हुए, लेकिन व्यावसायिक तर्क भी रखते हैं।

मुझे लगता है कि आपके मुख्य सवालों का जवाब है। जब हम कुछ और परतें जोड़ते हैं तो चीजें जटिल हो जाती हैं, जैसे रिपॉजिटरी लेयर। अक्सर यह सुझाव दिया जाता है कि इसे मॉडल में रखे गए व्यावसायिक तर्क द्वारा लागू किया जाना चाहिए (और इसलिए प्रत्येक डोमेन ऑब्जेक्ट में एक रिपॉजिटरी का संदर्भ होता है)। मेरे द्वारा लिखे गए मेरे लेख में मेरा तर्क है कि यह काफी अच्छा अभ्यास नहीं है। और यह वास्तव में सेवा की परत होना कोई बुरी बात नहीं है। वैसे, डोमेन-संचालित डिज़ाइन सेवा की परत को बाहर नहीं करता है, लेकिन इसे 'पतला' माना जाता है, और केवल डोमेन ऑब्जेक्ट्स को समन्वयित करता है (इसलिए वहां कोई व्यावसायिक तर्क नहीं है)।

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


बहुत बढ़िया बात! एक टिप्पणी: सेवाओं के साथ एक ही गड़बड़ है। कम से कम सेवाएँ अनुप्रयोग सेवाएँ और डोमेन सेवाएँ हो सकती हैं। एप्लिकेशन सेवा केवल एक पतली आवरण है, जो रिपॉजिटरी आदि से जानकारी एकत्र करती है। डोमेन सेवा व्यावसायिक तर्क प्रदान करती है, जो कि डोमेन मॉडल के संयोजन का उपयोग कर रही है या केवल सामान जो हमेशा डोमेन मॉडल में फिट नहीं होता है।
Artru

क्या होगा अगर आपके प्रोजेक्ट में डेटाबेस नहीं है। यह सेवा संदर्भों के साथ सहभागिता करता है। सभी डोमेन कक्षाएं और विधि इन संदर्भों से आती हैं। क्या यह परिदृश्य स्तरित संरचना के लिए फिट है?
user6395764

3

मेरी राय में,

नमूना -

व्यावसायिक तर्क नहीं होना चाहिए, यह प्लग करने योग्य होना चाहिए (WCF परिदृश्य की तरह)। इसका उपयोग देखने के लिए बाध्य करने के लिए किया जाता है, इसमें गुण होने चाहिए।

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

इसे "डोमेन सर्विसेज लेयर" पर रखा जाना चाहिए, यह पूरी तरह से अलग परत है। इसके अलावा, यहां "एप्लिकेशन सेवाएं" एक और परत जोड़ देगा।

ऐप लॉज़ बिजनेस लॉजिक को लागू करने के लिए डोमेन सर्विसेज लेयर से बात करता है और फिर मॉडल को अंतिम रूप से वापस करता है।

इसलिए, नियंत्रक मॉडल के लिए आवेदन सेवा से पूछेगा और प्रवाह की तरह हो जाएगा,

    Controller->Application Services(using domain services)->Model

2

MVC पैटर्न और Asp.net फ्रेमवर्क मॉडल क्या होना चाहिए पर कोई भेद नहीं करता है।

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

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

इस प्रकार के प्रश्न अत्यधिक विस्तृत और व्यक्तिपरक होते हैं, लेकिन मैं आपको और प्रत्येक व्यक्ति को उत्तर दे रहा हूं जिन्होंने आपको मतदान किया है, इसे समझ सकते हैं।

आपकी आवश्यकताओं / समयरेखाओं / संसाधनों को आपके सिस्टम की वास्तुकला में ब्लीड किया जाता है। यहां तक ​​कि राजस्व मॉडल पर भी असर पड़ सकता है। आपको उस पैटर्न पर भी विचार करना होगा जिसे आप शूट कर रहे हैं। DDD दृढ़ता-मॉडल अनुप्रयोगों की तुलना में बहुत अलग है और बीच में सभी ढलान भी कुछ एप्लिकेशन के लिए मान्य हैं। क्या आप ऐप का परीक्षण करने के लिए शूटिंग कर रहे हैं? इन सबका असर है।

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