मॉडल में व्यावसायिक तर्क क्यों रखा? क्या होता है जब मेरे पास कई प्रकार के भंडारण होते हैं?


70

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

अब मैं इस सवाल में पढ़ता हूं कि आपको हमेशा व्यापार तर्क को मॉडल में रखना चाहिए और यह कि नियंत्रक दृश्य के साथ गहराई से जुड़ा हुआ है।

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

और अगर मुझे एक और दृश्य चाहिए, तो मुझे दृश्य और नियंत्रक दोनों को फिर से लिखना होगा।

हो सकता है कि कोई समझाए कि मैं गलत क्यों हूं या कहीं और गया हूं?

जवाबों:


69

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

दो स्पष्टीकरण:

  • व्यापारिक तर्क शब्द यहाँ बेकार है, क्योंकि यह अस्पष्ट है। व्यावसायिक तर्क सभी तर्क के लिए एक छत्र शब्द है जिसे व्यवसाय-लोग परवाह करते हैं, इसे मात्र तकनीकी से अलग करते हैं जैसे किसी डेटाबेस में सामान को कैसे स्टोर किया जाए या इसे स्क्रीन पर कैसे प्रस्तुत किया जाए। दोनों डोमेन तर्क ("एक वैध ईमेल पता जैसा दिखता है ...") और वर्कफ़्लोज़ / व्यावसायिक प्रक्रियाएँ ("जब कोई उपयोगकर्ता साइन अप करता है, तो उसका ईमेल पता पूछें") को व्यावसायिक तर्क माना जाता है, जिसमें पूर्व स्पष्ट रूप से संबंधित है मॉडल और बाद वाला एप्लिकेशन लॉजिक जो कंट्रोलर में जाता है।
  • MVC स्क्रीन पर सामान रखने के लिए एक पैटर्न है और उपयोगकर्ता को इसके साथ बातचीत करने की अनुमति देता है, यह भंडारण को बिल्कुल भी निर्दिष्ट नहीं करता है । अधिकांश एमवीसी-फ्रेमवर्क पूर्ण स्टैक फ्रेमवर्क हैं जो केवल एमवीसी से परे जाते हैं और आपके डेटा को स्टोर करने में आपकी सहायता करते हैं, और क्योंकि जो डेटा संग्रहीत किया जाना चाहिए वह आमतौर पर मॉडल में पाया जाता है, ये फ्रेमवर्क आपके मॉडल को स्टोर करने के सुविधाजनक तरीके देते हैं। एक डेटाबेस में डेटा, लेकिन इसका MVC से कोई लेना-देना नहीं है। आदर्श रूप से, मॉडल दृढ़ता-अज्ञेय होना चाहिए और एक अलग प्रकार के भंडारण पर स्विच करना मॉडल-कोड को बिल्कुल भी प्रभावित नहीं करना चाहिए। पूर्ण विकसित आर्किटेक्चर के पास इसे संभालने के लिए एक दृढ़ता परत है।

4
अधिकांश एमवीसी-फ्रेमवर्क मॉडल में सभी स्टोरेज / डेटाबेस सामान को मिलाते हैं ताकि आपके मॉडल को स्टोर करना आसान हो (अक्सर आप फ्रेमवर्क मॉडल-क्लास का विस्तार करके) बनाते हैं। यह शायद भ्रम का स्रोत है। तकनीकी रूप से, आपके द्वारा लिखा गया मॉडल-कोड वास्तविक मॉडल (डोमेन लेयर) होना चाहिए, जबकि फ्रेमवर्क द्वारा प्रदान किया गया कोड स्टोरेज (हठ परत) से निपटना चाहिए। उदाहरण के लिए, User.find (...) (उपयोगकर्ता होने के साथ एक मॉडल) जैसा कुछ काम करता है क्योंकि फ्रेमवर्क ने मॉडल के भाग के रूप में रिपॉजिटरी पैटर्न को लागू किया।
9-13 को वाको

3
व्यू-कंट्रोलर-मॉडल-स्टोरेज सामान्य सिद्धांत है (हालाँकि M, V और C के बीच के संबंध को त्रिकोण के रूप में देखा जाना चाहिए)। जब आपका फ्रेमवर्क उनके "मॉडल" में स्टोरेज मिक्स करता है, तो यह इस तरह का काम करता है: व्यू-कंट्रोलर- (फ्रेमवर्क से स्टोरेज विरासत में मिलता है)।
9-13 बजे वाको

2
दृश्य-नियंत्रक-मॉडल-भंडारण बल्कि क्रूड है, क्योंकि यह सपाट नहीं होना चाहिए। उदाहरण के लिए, जब कोई नियंत्रक मॉडल प्राप्त करने के लिए User.find (...) जैसा कुछ करता है, तो वह डोमेन परत के माध्यम से जाने के बजाय सीधे भंडारण परत पूछता है।
9-13 को वाक्वो

2
अधिक सावधान लेयरिंग के साथ आर्किटेक्चर में, यह UserRepository.find () की तरह कुछ होगा। "मॉडल" से मेरा तात्पर्य फ्रेमवर्क द्वारा प्रदान किए गए "मॉडल" -क्लास से है, जो आपको विरासत में मिला है। User.find द्वारा उपयोगकर्ता-ऑब्जेक्ट लौटाया गया () इस अर्थ में एक उपयोगकर्ता का एक मॉडल है कि किसी ने मॉडल किया है कि कोई उपयोगकर्ता क्या है, उपयोगकर्ता कैसे व्यवहार करता है ...
Waquo

1
@flipdoubt व्यावसायिक तर्क कोई भी तर्क है जिसे उसी तरह रखा जाना चाहिए यदि आपने uwp ऐप कहने के लिए mvc से पोर्ट किया है।
एंडी

23

आप और प्रोग्रामिंग दुनिया के बड़े हिस्से गलतफहमी महसूस करते हैं कि एमवीसी भागों की भूमिकाएं क्या हैं। संक्षेप में, वे हैं:

मॉडल = डोमेन तर्क

देखें = आउटपुट तर्क

नियंत्रक = इनपुट तर्क

इसका मतलब यह है कि मॉडल संपूर्ण व्यावसायिक तर्क के लिए जिम्मेदार है: कुछ भी जो स्क्रीन पर विजेट्स से संबंधित है, प्रिंटर ड्राइविंग, HTML के रूप में डेटा आउटपुट, HTTP अनुरोधों को पार्स करने आदि से संबंधित नहीं है।

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

आप मल्टी-टीयर आर्किटेक्चर के बारे में भी पढ़ना चाह सकते हैं; जहाँ MVC एक तरफ़ा है (प्रवाह नियंत्रक है -> मॉडल -> दृश्य), मल्टी-टियर एक दो तरफ़ा चीज़ है (प्रस्तुति -> तर्क -> डेटा -> तर्क -> प्रस्तुति), और काफी कुछ MVC करने का ढोंग करने वाले फ्रेमवर्क वास्तव में थ्री-टीयर करते हैं, प्रस्तुति को देखने, लॉजिक से कंट्रोलर, और डेटा से मॉडल में प्रस्तुत करना।


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

@ A.Murray: बेशक मॉडल में कोड का एक अखंड होना नहीं है, और इसे दृढ़ता, डेटा संरचनाओं और डोमेन तर्क में अलग करना आमतौर पर बहुत मायने रखता है। फिर भी, MVC इन तीन चिंताओं को मॉडल में एक साथ रखता है। किसी भी स्थिति में, जब आपके नियंत्रकों और विचारों में डोमेन लॉजिक होता है, तो यह अब वास्तविक MVC नहीं है।
tdammers

@ दोस्त, मुझे आपके उत्तर की दृढ़ता और तर्क पर ध्यान केंद्रित करना पसंद है। आपके विचार में, आवेदन की चिंताएं जैसे हठ और लेनदेन प्रसंस्करण कहां हैं? MVC की तरह लगता है कि MVCS की तरह एक चार अक्षर का संक्षिप्त नाम होना चाहिए जहां S सेवा के लिए है।
फ्लिपडॉब

15

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

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

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

अपडेट करें

मेरा सुझाव हेक्सागोनल वास्तुकला पर आधारित है । एक हेक्सागोनल वास्तुकला में, आपका डोमेन मॉडल (व्यावसायिक तर्क) कोर पर है। यह कोर अनुप्रयोग सेवाओं द्वारा एनकैप्सुलेटेड है जो एक मुखौटा के रूप में कार्य करता है । अनुप्रयोग सेवाएँ सरल वर्ग हैं जो आपके डोमेन में मामलों का उपयोग करने के लिए इसी तरीके हैं। एप्लिकेशन सेवाओं पर गहन चर्चा के लिए , डोमेन-संचालित डिज़ाइन में सेवाओं पर एक नज़र डालें । कोड नमूने में PurchaseOrderServiceएक क्रय डोमेन के लिए एक आवेदन सेवा होती है। (ध्यान दें कि एक एप्लिकेशन सेवा डोमेन-संचालित डिज़ाइन का उपयोग नहीं करती है।)

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

इस समाधान में निश्चित रूप से एक समाधान से आगे बढ़ने वाले हिस्से होते हैं जो नियंत्रक में व्यापारिक तर्क रखता है और आपको कमियों और लाभों का वजन करना चाहिए। कारण यह है कि मैं सुझाव देता हूं क्योंकि मैं जटिलता से निपटने के लिए व्यावसायिक तर्क को प्रस्तुति परत से अलग रखना पसंद करता हूं। यह अधिक महत्वपूर्ण हो जाता है क्योंकि अनुप्रयोग बढ़ता है।


ऐसा लगता है कि आप एमवीसी और एमवीवीएम के एक कमीने का वर्णन कर रहे हैं जिसमें नियंत्रक और दृश्य मॉडल दोनों हैं। इसके अलावा, मुझे लगता है कि आप जिस वास्तुकला का वर्णन कर रहे हैं वह ओपी की जरूरतों के लिए थोड़ा भारी हो सकता है।
9-13 को वाको

ईमानदारी से कहूं तो मुझे वाको का जवाब ज्यादा पसंद है। मुख्य रूप से इसलिए कि मुझे 'आवेदन सेवाओं' से कोई मतलब नहीं है। क्या आप उस शब्द की व्याख्या कर सकते हैं? मेरा GoogleFU यहां काम नहीं कर रहा है क्योंकि ऐसा लगता है।
स्टीफन विंकलर

1
@Aquo मैं सहमत हूं कि प्रस्तावित वास्तुकला ओवरकिल हो सकता है, हालांकि इस पर विचार किया जाना चाहिए। मैंने एमवीवीएम का कोई उल्लेख नहीं किया है जो प्रस्तुति परत को लागू करने का एक और तरीका है। अनुप्रयोग सेवाएँ लागू होती हैं, चाहे आप एमवीसी या एमवीवीएम का उपयोग करें और मैंने जो कुछ भी सुझाया है वह दोनों के संयोजन को इंगित करता है।
eulerfx

1

इस बात पर निर्भर करता है कि आपको व्यावसायिक तर्क से क्या मतलब है। मॉडल की सामग्री को अर्थ देने वाला कोई भी "तर्क" मॉडल में होना चाहिए। लिंक किए गए प्रश्न में, उच्चतम मतदान वाला उत्तर "व्यापार तर्क" को डेटा से संबंधित कुछ भी परिभाषित करता है; यह इस दृष्टिकोण से समझ में आता है कि किसी व्यवसाय का डेटा उसका व्यवसाय है!

मैंने एक बार रेल के निर्माता द्वारा एक उदाहरण देखा (मुझे लगता है) जो इस बारे में बिल्कुल चल रहा था - मॉडल में "व्यावसायिक तर्क" नहीं डाल रहा है। उनका उदाहरण एक नियंत्रक वर्ग था और ऐप पंजीकरण और लॉगिन के लिए विधि - मॉडल में एक डेटाबेस (डेटाबेस) के खिलाफ डालने या छोड़ने से पहले प्लेनटेक्स्ट में एक दिया गया पासवर्ड एन्क्रिप्ट किया गया था।

मैं ऐसे कुछ बेहतर उदाहरण के बारे में नहीं सोच सकता जो नियंत्रक तर्क नहीं है और जो सीधे मॉडल में है।

पोर्टेबिलिटी चिंताओं को दूर करते हुए, मॉडल असंख्य डेटा स्टोर के लिए एक इंटरफ़ेस हो सकता है। यह यहां है कि किसी को वेदर पर भ्रम हो सकता है या नहीं मॉडल इंटरफ़ेस वास्तव में "नियंत्रक" है।

आम तौर पर, नियंत्रक मॉडल और दृश्य को जोड़ता है (जो कि ऐप का मांस-और-आलू हैं।) कोको विकास में यह उस बिंदु पर सरलीकृत हो सकता है जहां नियंत्रक XCode GUI (नियंत्रक ऑब्जेक्ट और बाइंडिंग) के माध्यम से नियंत्रित किया जाता है।

MVC पर GoF के "डिज़ाइन पैटर्न" सेक्शन को शिथिल रूप से उद्धृत किया गया है:

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

MVC सभी UI के बारे में है। फोकस मॉडल और दृश्य पर है - डेटा को परिभाषित और प्रदर्शित करना। "सदस्यता / अधिसूचित प्रोटोकॉल" पर ध्यान दें - यह वह जगह है जहां आपका नियंत्रक आता है। आप अपने इच्छित सभी विचारों का निर्माण कर सकते हैं; जब तक वे प्रोटोकॉल का पालन करते हैं तब तक आपको मॉडल या नियंत्रक को कभी नहीं छूना होगा।

यदि आप विशेष रूप से वेब विकास की बात कर रहे हैं, तो IMHO कई लोकप्रिय वेब फ्रेमवर्क MVC और इसकी घटक परिभाषाओं के साथ तेज और ढीले हैं।


मैं C # / Java (केवल कुछ प्रोजेक्ट्स) डेवलपर हूं। ऐसा लगता है कि मैंने गलत समझा कि मॉडल क्या करता है। कंट्रोलर में 'बिजनेस लॉजिक' डालना वास्तव में केवल एक नतीजा था (मेरी विचार की ट्रेन चली गई 'ठीक है, मैंने डेटा के लिए मॉडल पढ़ा है: (डेटाबेस कनेक्शन / स्टोरेज पढ़ें), इसलिए मेरे बिजनेस लॉजिक को कंट्रोलर में लाने की जरूरत है क्योंकि मैंने डेटाबेस में डेटा संग्रहीत करने से पहले इसे लागू किया है। बस नियंत्रक से सब कुछ एक स्तर नीचे ले जाना होगा। वास्तव में, जो मुझे वर्तमान में एक कार्यक्रम में MySQL और MSSQL का समर्थन करता है - एक समस्या हल करता है
स्टीफन विंकलर

0

आप एक सेवा परत का परिचय क्यों नहीं देते?

तब आपका नियंत्रक दुबला और अधिक पठनीय होगा, फिर आपके सभी नियंत्रक कार्य शुद्ध कार्य होंगे।

सर्विस लेयर के भीतर आपको जितनी जरूरत हो उतनी बिजनेस लॉजिक का विघटन कर सकते हैं। कोड पुन: प्रयोज्य बेहतर है और मॉडल और रिपॉजिटरी पर कोई प्रभाव नहीं है।

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