MVC में व्यावसायिक तर्क [बंद]
जवाबों:
मॉडल में व्यावसायिक नियम चलते हैं।
कहते हैं कि आप एक मेलिंग सूची के लिए ईमेल प्रदर्शित कर रहे थे। उपयोगकर्ता ईमेलों में से एक के बगल में "हटाएं" बटन पर क्लिक करता है, नियंत्रक एंट्री एन को हटाने के लिए मॉडल को सूचित करता है, फिर उस मॉडल को बदलने के दृश्य को सूचित करता है।
शायद व्यवस्थापक का ईमेल सूची से कभी नहीं हटाया जाना चाहिए। यह एक व्यावसायिक नियम है, यह ज्ञान मॉडल में है। दृश्य अंततः इस नियम को किसी भी तरह से प्रदर्शित कर सकता है - शायद मॉडल एक "IsDeletable" संपत्ति को उजागर करता है जो कि व्यापार नियम का एक फ़ंक्शन है, ताकि दृश्य में हटाए गए बटन कुछ प्रविष्टियों के लिए अक्षम हो - लेकिन नियम स्वयं समाहित नहीं है दृश्य में।
मॉडल अंततः आपके डेटा के लिए द्वारपाल है। आपको यूआई को छूने के बिना अपने व्यापार तर्क का परीक्षण करने में सक्षम होना चाहिए।
सभी की मुट्ठी:
मेरा मानना है कि आप एमवीसी पैटर्न और एन-टियर-आधारित डिजाइन सिद्धांतों का मिश्रण कर रहे हैं।
एमवीसी दृष्टिकोण का उपयोग करने का मतलब यह नहीं है कि आपको अपने आवेदन को परत नहीं करना चाहिए।
यदि आप MVC को प्रस्तुति परत के विस्तार की तरह देखते हैं तो यह मदद कर सकता है।
यदि आप एमवीसी पैटर्न के अंदर गैर-प्रस्तुति कोड डालते हैं तो आप बहुत जल्द एक जटिल डिजाइन में समाप्त हो सकते हैं।
इसलिए मेरा सुझाव है कि आप अपने व्यापार तर्क को एक अलग व्यावसायिक परत में रखें।
बस इस पर एक नज़र है: मल्टीटियर आर्किटेक्चर के बारे में विकिपीडिया लेख
यह कहता है:
आज, एमवीसी और इसी तरह के मॉडल-व्यू-प्रस्तोता (एमवीपी) सेपरेशन डिज़ाइन पैटर्न के अलगाव हैं जो विशेष रूप से एक बड़ी प्रणाली की प्रस्तुति परत पर लागू होते हैं ।
वैसे भी ... जब एक एंटरप्राइज़ वेब एप्लिकेशन के बारे में बात हो रही है तो यूआई से व्यावसायिक लॉजिक परत पर कॉल को (प्रस्तुति) नियंत्रक के अंदर रखा जाना चाहिए।
ऐसा इसलिए है क्योंकि नियंत्रक वास्तव में कॉल को एक विशिष्ट संसाधन के लिए संभालता है, व्यापार तर्क के लिए कॉल करके डेटा पर सवाल उठाता है और डेटा (मॉडल) को उचित दृश्य से जोड़ता है।
मड ने आपको बताया कि व्यावसायिक नियम मॉडल में चलते हैं।
यह सच भी है, लेकिन उन्होंने (प्रेजेंटेशन) मॉडल ('एमवीसी में एम') और टियर-आधारित एप्लिकेशन डिज़ाइन के डेटा लेयर मॉडल को मिलाया।
तो यह आपके डेटाबेस से संबंधित व्यावसायिक नियमों को आपके आवेदन के मॉडल (डेटा परत) में रखने के लिए मान्य है ।
लेकिन आपको उन्हें अपने एमवीसी-संरचित प्रस्तुति परत के मॉडल में नहीं रखना चाहिए क्योंकि यह केवल विशिष्ट यूआई पर लागू होता है।
यह तकनीक इस बात से स्वतंत्र है कि आप एक डोमेन संचालित डिज़ाइन या लेनदेन स्क्रिप्ट आधारित दृष्टिकोण का उपयोग करते हैं या नहीं।
मुझे लगता है कि आप के लिए कल्पना:
प्रस्तुति परत: मॉडल - दृश्य - नियंत्रक
व्यावसायिक परत: डोमेन तर्क - अनुप्रयोग तर्क
डेटा लेयर: डेटा रिपॉजिटरी - डेटा एक्सेस लेयर
मॉडल जो आप ऊपर देखते हैं, इसका मतलब है कि आपके पास एक एप्लिकेशन है जो एमवीसी, डीडीडी और एक डेटाबेस-इंडिपेंडेड डेटा लेयर का उपयोग करता है।
यह एक बड़ा एंटरप्राइज़ वेब एप्लिकेशन डिज़ाइन करने के लिए एक सामान्य दृष्टिकोण है।
लेकिन आप एक साधारण गैर-डीडीडी व्यावसायिक परत (डोमेन तर्क के बिना एक व्यावसायिक परत) और एक साधारण डेटा परत का उपयोग करने के लिए इसे नीचे भी सिकोड़ सकते हैं जो सीधे एक विशिष्ट डेटाबेस में लिखते हैं।
आप संपूर्ण डेटा-लेयर को छोड़ भी सकते हैं और डेटाबेस को सीधे व्यावसायिक लेयर से एक्सेस कर सकते हैं, हालाँकि मैं इसकी अनुशंसा नहीं करता।
Thats 'चाल ... मुझे आशा है कि यह मदद करता है ...
[नोट:] आपको इस तथ्य के बारे में भी पता होना चाहिए कि आजकल एक आवेदन में सिर्फ एक "मॉडल" से अधिक है। आमतौर पर, एप्लिकेशन की प्रत्येक परत का अपना मॉडल होता है। प्रस्तुति परत का मॉडल विशिष्ट है, लेकिन अक्सर उपयोग किए गए नियंत्रणों से स्वतंत्र होता है। व्यवसाय परत में एक मॉडल भी हो सकता है, जिसे "डोमेन-मॉडल" कहा जाता है। यह आमतौर पर मामला है जब आप एक डोमेन-संचालित दृष्टिकोण लेने का फैसला करते हैं। इस "डोमेन-मॉडल" में डेटा के साथ-साथ व्यावसायिक तर्क (आपके कार्यक्रम का मुख्य तर्क) शामिल है और आमतौर पर प्रस्तुति परत से स्वतंत्र है। प्रस्तुति परत आमतौर पर डेटा परत को डेटा पढ़ने या लिखने के लिए एक निश्चित "घटना" (बटन दबाया आदि) पर व्यापार परत को कॉल करती है। डेटा लेयर में यह स्वयं का मॉडल भी हो सकता है, जो आमतौर पर डेटाबेस से संबंधित होता है।
सवाल यह है कि यह एमवीसी अवधारणा में कैसे फिट होता है?
उत्तर -> यह नहीं है!
अच्छा - यह थोड़े करता है, लेकिन पूरी तरह से नहीं।
ऐसा इसलिए है क्योंकि MVC एक दृष्टिकोण है जिसे 1970 के अंत में स्मॉलटाक -80 प्रोग्रामिंग भाषा के लिए विकसित किया गया था। उस समय GUI और पर्सनल कंप्यूटर काफी असामान्य थे और वर्ल्ड वाइड वेब का आविष्कार भी नहीं किया गया था! आज की अधिकांश प्रोग्रामिंग लैंग्वेज और IDEs का विकास 1990 के दशक में हुआ था। उस समय 1970 के दशक में कंप्यूटर और यूजर इंटरफेस पूरी तरह से अलग थे।
आपको उस बात को ध्यान में रखना चाहिए जब आप MVC के बारे में बात करते हैं।
मार्टिन फाउलर ने MVC, MVP और आज के GUI के बारे में बहुत अच्छा लेख लिखा है।
व्यापार तर्क शब्द मेरे विचार में सटीक परिभाषा नहीं है। इवांस ने अपनी पुस्तक, डोमेन ड्रिवेन डिज़ाइन, दो प्रकार के व्यावसायिक तर्क के बारे में बात की:
- डोमेन तर्क।
- आवेदन तर्क।
यह अलगाव मेरे विचार में बहुत स्पष्ट है। और इस अहसास के साथ कि विभिन्न प्रकार के व्यावसायिक नियम भी हैं, यह अहसास होता है कि वे सभी एक ही जगह नहीं जाते हैं।
डोमेन लॉजिक वह तर्क है जो वास्तविक डोमेन से मेल खाता है। इसलिए यदि आप एक अकाउंटिंग एप्लिकेशन बना रहे हैं, तो डोमेन रूल्स अकाउंट, पोस्टिंग, टैक्सेशन आदि से संबंधित नियम होंगे। एक फुर्तीली सॉफ्टवेयर प्लानिंग टूल में, नियम सामान की तरह होंगे जो बैकलॉग में वेग और स्टोरी पॉइंट के आधार पर रिलीज़ डेट आदि की गणना करते हैं। आदि।
इन दोनों प्रकार के अनुप्रयोग के लिए, CSV आयात / निर्यात प्रासंगिक हो सकता है, लेकिन CSV आयात / निर्यात के नियमों का वास्तविक डोमेन से कोई लेना-देना नहीं है। इस तरह का तर्क एप्लीकेशन लॉजिक है।
डोमेन तर्क सबसे निश्चित रूप से मॉडल परत में जाता है। मॉडल डीडीडी में डोमेन परत के अनुरूप होगा।
एप्लिकेशन लॉजिक हालांकि जरूरी नहीं कि उसे मॉडल लेयर में रखा जाए। इसे सीधे नियंत्रकों में रखा जा सकता है, या आप उन नियमों की मेजबानी करने के लिए एक अलग अनुप्रयोग परत बना सकते हैं। इस मामले में सबसे तार्किक क्या है यह वास्तविक आवेदन पर निर्भर करेगा।
A1 : व्यापार तर्क Modelमें भाग लेने के लिए चला जाता है MVC। भूमिका Modelमें डेटा और व्यावसायिक तर्क होते हैं। Controllerदूसरी ओर उपयोगकर्ता इनपुट प्राप्त करने और क्या करना है यह तय करने के लिए जिम्मेदार है।
A2 : A Business Ruleका हिस्सा है Business Logic। उनका एक has aरिश्ता है। Business Logicहै Business Rules।
देख लेना Wikipedia entry for MVC। अवलोकन पर जाएं जहां यह MVCपैटर्न के प्रवाह का उल्लेख करता है ।
इसके अलावा को देखो Wikipedia entry for Business Logic। यह उल्लेख किया गया है कि Business Logicके शामिल है Business Rulesऔर Workflow।
जैसा कि कुछ उत्तरों ने बताया है, मेरा मानना है कि मल्टी टीयर बनाम एमवीसी वास्तुकला की कुछ गलतफहमी है।
मल्टी टियर आर्किटेक्चर में आपके एप्लिकेशन को स्तरों / परतों (जैसे प्रस्तुति, व्यावसायिक तर्क, डेटा एक्सेस) में तोड़ना शामिल है
MVC एक आवेदन की प्रस्तुति परत के लिए एक वास्तुशिल्प शैली है। गैर तुच्छ अनुप्रयोगों के लिए, बिजनेस लॉजिक / बिजनेस रूल्स / डेटा एक्सेस को सीधे मॉडल, व्यू या कंट्रोलर में नहीं रखा जाना चाहिए। ऐसा करने के लिए आपकी प्रेजेंटेशन लेयर में बिजनेस लॉजिक रखा जाएगा और इस तरह से आपके कोड का पुन: उपयोग और रखरखाव कम हो जाएगा।
मॉडल व्यावसायिक तर्क रखने के लिए एक बहुत ही उचित विकल्प है, लेकिन एक बेहतर / अधिक बनाए रखने योग्य दृष्टिकोण आपकी प्रस्तुति परत को आपके व्यवसाय तर्क परत से अलग करना और एक व्यावसायिक तर्क परत बनाना है और ज़रूरत पड़ने पर बस अपने मॉडल से व्यावसायिक तर्क परत को कॉल करना है। व्यापार तर्क परत डेटा एक्सेस परत में कॉल कॉल बदले में होगी।
मैं यह बताना चाहता हूं कि एमवीसी घटकों में से एक में व्यावसायिक तर्क और डेटा एक्सेस को मिलाने वाले कोड का पता लगाना असामान्य नहीं है, खासकर यदि एप्लिकेशन कई स्तरों का उपयोग करके आर्किटेक्चर नहीं किया गया था। हालांकि, अधिकांश उद्यम अनुप्रयोगों में, आप आमतौर पर प्रस्तुति स्तर के भीतर एक एमवीसी वास्तुकला के साथ बहु स्तरीय आर्किटेक्चर पाएंगे।
यह एक उत्तर दिया गया प्रश्न है, लेकिन मैं अपना "एक प्रतिशत" दूंगा:
व्यवसाय के नियम मॉडल में हैं। "मॉडल" में हमेशा (तार्किक रूप से या शारीरिक रूप से अलग) होते हैं:
- प्रस्तुति मॉडल - कक्षाओं का एक सेट जो दृश्य में उपयोग के लिए अच्छी तरह से अनुकूल है (यह विशिष्ट UI / प्रस्तुति के अनुरूप है),
- डोमेन मॉडल - मॉडल का यूआई-स्वतंत्र हिस्सा, और
- भंडार - "मॉडल" का भंडारण-जागरूक हिस्सा।
व्यवसाय नियम डोमेन मॉडल में रहते हैं, "प्रस्तुति" मॉडल के लिए एक प्रस्तुति-उपयुक्त रूप में उजागर होते हैं और कभी-कभी "डेटा परत" में दोहराए जाते हैं (या लागू भी होते हैं)।
MVC प्रोजेक्ट के लिए मॉडल में अपनी व्यावसायिक परत डालने का कोई मतलब नहीं है।
यह कहें कि आपके बॉस ने प्रस्तुति की परत को किसी और चीज़ में बदलने का फैसला किया है, तो आप चौक जाएंगे! व्यवसाय की परत एक अलग विधानसभा होनी चाहिए। एक मॉडल में डेटा परत होती है जो व्यापार परत से आती है जो प्रदर्शन करने के लिए दृश्य में जाती है। उदाहरण के लिए पोस्ट पर, मॉडल एक व्यक्ति वर्ग को बांधता है जो व्यवसाय की परत में रहता है और कॉल पर्सनबीस.वेपर्सन (पी); जहाँ p व्यक्ति वर्ग है। यहाँ मैं क्या कर रहा हूँ (BusinessError वर्ग गायब है, लेकिन BusinessLayer में भी जाएगा):
Q1:
बिजनेस लॉजिक्स को दो श्रेणियों में माना जा सकता है:
डोमेन लॉजिक्स जैसे एक ईमेल पते पर नियंत्रण (विशिष्टता, बाधाएं आदि), चालान के लिए उत्पाद की कीमत प्राप्त करना, या, अपने उत्पाद की वस्तुओं के आधार पर खरीदारी की कुल कीमत की गणना करना।
अधिक व्यापक और जटिल वर्कफ़्लोज़ जिन्हें व्यावसायिक प्रक्रियाएं कहा जाता है, जैसे छात्र के लिए पंजीकरण प्रक्रिया को नियंत्रित करना (जिसमें आमतौर पर कई चरणों को शामिल किया जाता है और विभिन्न जांचों की आवश्यकता होती है और अधिक जटिल बाधाएं होती हैं)।
पहली श्रेणी में चला जाता है मॉडल और दूसरा एक के अंतर्गत आता है नियंत्रक । ऐसा इसलिए है क्योंकि दूसरी श्रेणी के मामले व्यापक अनुप्रयोग लॉजिक्स हैं और उन्हें मॉडल में डालने से मॉडल का अमूर्त मिश्रण हो सकता है (उदाहरण के लिए, यह स्पष्ट नहीं है कि क्या हमें उन निर्णयों को एक मॉडल वर्ग या किसी अन्य में डालने की आवश्यकता है, क्योंकि वे संबंधित हैं दोनों को!)।
इस देखें जवाब मॉडल और नियंत्रक के बीच एक विशिष्ट गौरव के लिए, इस लिंक बहुत सटीक परिभाषा के लिए है और यह भी इस लिंक एक अच्छा एंड्रॉयड उदाहरण के लिए।
मुद्दा यह है कि दोनों के ऊपर "मड" और "फ्रैंक" द्वारा उल्लिखित नोट्स सही हो सकते हैं और साथ ही "पीट" (व्यावसायिक तर्क को मॉडल, या नियंत्रक में, व्यावसायिक तर्क के प्रकार के अनुसार रखा जा सकता है)।
अंत में, ध्यान दें कि MVC संदर्भ से संदर्भ में भिन्न होता है। उदाहरण के लिए, एंड्रॉइड एप्लिकेशन में, कुछ वैकल्पिक परिभाषाएं सुझाई जाती हैं जो वेब-आधारित लोगों से भिन्न होती हैं ( उदाहरण के लिए इस पोस्ट को देखें)।
Q2:
व्यवसाय तर्क अधिक सामान्य है और (जैसा कि ऊपर उल्लेखित "डीकॉलोन") हमारे बीच निम्नलिखित संबंध हैं:
व्यापार नियम ⊂ व्यापार लॉजिक्स
CRUD डेटाबेस ऑपरेशन के लिए मॉडल = कोड।
नियंत्रक = उपयोगकर्ता की कार्रवाइयों का जवाब देता है, और संगठन के लिए विशिष्ट व्यावसायिक नियमों के अधीन, मॉडल के लिए डेटा पुनर्प्राप्ति या हटाने / अपडेट के लिए उपयोगकर्ता अनुरोधों को पारित करता है। इन व्यावसायिक नियमों को सहायक वर्गों में लागू किया जा सकता है, या यदि वे बहुत जटिल नहीं हैं, तो सीधे नियंत्रक कार्यों में। नियंत्रक अंततः दृश्य को खुद को अपडेट करने के लिए कहता है ताकि एक नए प्रदर्शन के रूप में उपयोगकर्ता को प्रतिक्रिया दे, या एक संदेश जैसे 'अपडेट, धन्यवाद', आदि।
देखें = UI जो मॉडल पर एक क्वेरी के आधार पर उत्पन्न होता है।
व्यावसायिक नियम कहां जाने चाहिए, इसके बारे में कोई कठिन और तेज नियम नहीं हैं। कुछ डिजाइनों में वे मॉडल में जाते हैं, जबकि अन्य में उन्हें नियंत्रक के साथ शामिल किया जाता है। लेकिन मुझे लगता है कि उन्हें कंट्रोलर के साथ रखना बेहतर है। डेटाबेस कनेक्टिविटी के बारे में मॉडल को केवल चिंता करने दें।