2013-09-01 13 views
51

सबसे पहले, मैंने इसके कई प्रश्न देखे हैं, लेकिन इसके पीछे पर्याप्त तर्क नहीं है। अगर मेरा प्रश्न पर्याप्त नहीं है और हटाया जाना चाहिए तो मैं समझूंगा।एमवीसी: व्यापार तर्क कहां रखा जाए?

मैंने देखा है, उदाहरण के लिए, this और 45+ वोट किए गए उत्तर का कहना है कि वह आपको मॉडल में व्यापार तर्क डालने की सलाह देता है, जो कि बहुत तार्किक लगता है।

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

यूट्यूब पर एक व्यक्ति ने मुझसे पूछा कि क्या वह सभी तर्क अपने मॉडल में डालकर सही है और पहले मैं नहीं था! तब मैंने सोचना शुरू कर दिया कि शायद वह सही था !?

तो, आखिरकार, मैं अपना व्यवसाय तर्क कहां डालूं? यदि यह मॉडल कक्षाओं में है, तो नियंत्रक में मौजूद विधि में कितना कोड स्वस्थ राशि माना जाना चाहिए? एक नियंत्रक में मॉडल से कुछ विधि को कॉल करने के लिए एक पंक्ति और फिर दृश्य में वापसी?

+1

व्यापार तर्क नियंत्रकों में चला जाता है। आदर्श तर्क मॉडल में चला जाता है। मॉडल तर्क ऐसी चीजें हैं जो विशेष रूप से मॉडल के साथ सौदा करती हैं। सेटर्स/गेटर्स/गुण/योजक/रिमूवर इत्यादि – crush

+1

@ क्रश: मैं सहमत नहीं हूं। जैसा कि मैंने पढ़ा है - "एक मॉडल ऑब्जेक्ट में एप्लिकेशन का डेटा और" व्यवसाय तर्क "होता है और" नियंत्रक ऑब्जेक्ट मॉडल से संबंध रखता है और ऑब्जेक्ट्स को एकसाथ देखता है। " – ChiefTwoPencils

+0

@ बॉबी डिजीटल - क्या आप स्रोत से लिंक प्रदान कर सकते हैं? :) –

उत्तर

43

मैं कुछ कारणों से मॉडल में डोमेन तर्क डालना पसंद करता हूं।

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

  2. यदि आप नियंत्रक में डोमेन तर्क डालते हैं, तो विभिन्न ऐप्स के बीच या यहां तक ​​कि विभिन्न नियंत्रकों के बीच साझा करना उतना आसान नहीं है।

+2

हां, मुझे वास्तव में '# 2' पसंद आया क्योंकि मुझे स्वयं नियंत्रकों के बीच साझा करना मुश्किल था (इस तरह के तरीकों को स्थिर के रूप में उपयोग करना था)! –

+0

हां @ एंड्रियस नारुसेविचियस, ऐसा मत करो। आपको अपनी निर्भरताओं को नियंत्रकों में डालने और इंजेक्ट करना चाहिए और अन्य नियंत्रकों पर भरोसा नहीं करना चाहिए। –

+0

ध्यान दें कि मुझे लगता है कि यह उत्तर "डोमेन मॉडल" (क्लासिक एमवीसी पैटन के एम भाग) के बारे में बात करता है जो कुछ एएसपी.NET एमवीसी "मॉडल" (एमवीवीएम पैटर्न का हिस्सा) से संबंधित नहीं है। –

32

मुझे अपने मॉडल को साफ रखना पसंद है Ie. बस गुणों और कोई व्यापार तर्क के साथ। मुझे हमेशा लगता है कि नियंत्रक में निर्भरता को इंजेक्ट करना अच्छा होता है और इन निर्भरताओं में मेरे मॉडल पर तर्क शामिल होता है। मुझे जहां भी संभव हो, एक जिम्मेदारी सिद्धांत का पालन करना पसंद है और मुझे लगता है कि कई तरीकों वाले मॉडल बहुत जल्दी फूले हुए हैं। दोनों के लिए पेशेवरों और विपक्ष हैं, कई निर्भरताओं को इंजेक्शन देने के लिए एक ओवरहेड है, फिर भी अलगाव में परीक्षण करने की अनुमति देता है और कक्षाओं को सरल रखता है और आप दुबला नियंत्रक होने लगेंगे। मेरे तर्क के बावजूद वास्तव में कक्षा के सदस्यों के रूप में मेरे मॉडल पर मौजूद नहीं है, यह अभी भी व्यापार तर्क है। मेरे पास नियंत्रक में परिभाषित व्यावसायिक तर्क नहीं है क्योंकि Httpcontext जैसी चीजों की नकल करना एक दुःस्वप्न और अनावश्यक है।

+4

+1 पूरी तरह से सहमत हैं। मैंने सोचा कि मैं अकेला था जो मॉडलों की जिम्मेदारियों को न्यूनतम रखने के लिए पसंद करता था! – Lee

+0

आपके द्वारा किए जाने वाले कार्यों के लिए कुछ छोटे कोड स्निपेट देखना बहुत अच्छा होगा। आपकी निर्भरताओं को इंजेक्ट करते समय आप किस नामकरण सम्मेलन के लिए जाते हैं? – Luke

+1

निश्चित रूप से, वह मेरे लॉगिन नियंत्रक के लिए एक गलती है https://gist.github.com/markwalsh-liverpool/8fb361a9df0dcf034caf –

19

व्यापार तर्क समस्या डोमेन और सब कुछ अंतर्गत आता है कि करने के लिए समस्या डोमेन मॉडल MVC में को जाता है के अंतर्गत आता है।

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

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

+0

मैं इन सब से सहमत हूं। हालांकि, मुझे लगता है कि मॉडल में कक्षाओं को कैसे व्यवस्थित करना है, ईएफ के साथ esp से बहुत भ्रम आता है। आईई: क्या आप आंशिक कक्षाओं का उपयोग करते हैं और विभिन्न सी # फाइलों में तर्क का निर्माण करते हैं? ईएफ के लिए एक फ़ाइल और तर्क के लिए एक फ़ाइल? – 40Alpha

2

मुझे अपने मॉडल को भी साफ रखना पसंद है (रेफरी: @ मार्क वॉल्श)। नियंत्रकों में एम्बेडेड तर्क का पुन: उपयोग करने में सक्षम नहीं होने की समस्या निर्भरता इंजेक्शन के माध्यम से आसानी से पार हो सकती है, या, यदि आपको लगता है कि इसमें बहुत अधिक होगा, तो इंटरफेस के माध्यम से अपने व्यवसाय/डोमेन तर्क का पर्दाफाश करें और नियंत्रकों में अग्रभाग पैटर्न का उपयोग करें। इस तरह आपको अपनी आवश्यक कार्यक्षमता मिलती है, लेकिन दोनों नियंत्रकों और मॉडल को अच्छे और साफ रखें।

1

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

1.WebApi नियंत्रक में लिखा जा सकता है: एक WebAPI नियंत्रक का उपयोग करने का लाभ यह है कि आप इन सेवाओं के रूप में बाद में अन्य उपकरणों के लिए अपने कोड बनाने का पर्दाफाश कर सकते हैं reuseable।

2. बाल/आम commonent: जो विशिष्ट उपयोग किया है और एक API के रूप में उजागर नहीं किया जा सकता है, इस वर्ग में पुश किया जा सकता कुछ लॉजिक्स रहे हैं।

3. रिपोजिटरी: सभी डेटाबेस संबंधित प्रश्न एक भंडार में जोड़े गए हैं। एक सामान्य भंडार हो सकता है जो प्रत्येक तालिका के लिए सभी कार्यों (सीआरयूडी संचालन) या विशिष्ट भंडार लागू करेगा। किए जाने वाले संचालन के आधार पर।

7

मेरी टीम वेबफॉर्म (एएसपीनेट) से एमवीसी में स्थानांतरित होने पर अनुसंधान के बहुत सारे थे और निम्नलिखित संरचना के साथ आया। मेरे अनुसार यह नहीं है कि आवेदन कितना बड़ा या छोटा है। कोड को साफ और स्पष्ट रखने के बारे में।

DALProject

AccountsDAL.cs --- > Calls SP or any ORM if ur using any 

BLLProject

AccountsBLL.cs ---> Calls DAL 

WebProject

Model 
    AccountsModel --- > Contains properties And call BLL 
Controllers 
    IndexController ---> Calls Models and returns View 
Views 
    Index 

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

0

मुझे पता है कि यह एमवीसी के बारे में एक सवाल है, लेकिन मुझे लगता है कि मैं जो उदाहरण दे रहा हूं (वेब ​​एपीआई) उपयोगी होगा।

मैं अपना पहला वेब एपीआई विकसित कर रहा हूं और मैं अन्य अनुप्रयोगों से व्यवसाय तर्क का पुनः उपयोग कर रहा हूं। विशिष्ट होने के लिए, यह बाहरी डीएलएल से आता है, इसलिए मेरी एपीआई को एसएपी समाधान के साथ "बात" करने के लिए प्रयोग किया जाता है, पीओ से अनुरोध प्राप्त होता है और प्रतिक्रियाएं वापस भेजती हैं।

मैं अपने नियंत्रक में अपना तर्क (पहले से लागू) कैसे डाल सकता हूं? मुझे इसकी आवश्यकता नहीं है। मेरा नियंत्रक केवल डेटा को वापस भेजने के लिए अनुरोधों को सत्यापित करेगा, प्रतिक्रियाओं को लिख देगा और जवाब देगा।

मैं व्यूमोडेल कक्षाओं के साथ काम कर रहा हूं और उनके पास ट्रांसफरऑब्जेक्ट्स (जो बाहरी डीएलएल से आता है) से जानकारी पढ़ने के लिए और एक व्यूमोडेल में अनुवाद करने के लिए बस मैपिंग फ़ंक्शन होना चाहिए।

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

मैं अपने व्यापार तर्क को एक निर्भरता के रूप में देख रहा हूं जिसे मैं नियंत्रक में इंजेक्ट करता हूं।

मैंने यूनिट टेस्टेबल समाधान प्रदान करने के लिए विरासत में बहुत से रिफैक्टरिंग की है, मुझे इस समाधान को प्रदान करने के लिए कई इंटरफेस बनाना और विरासत में कुछ डिज़ाइन पैटर्न लागू करना था।

मेरे दृष्टिकोण में, व्यापार परत आवेदन के अलावा, अन्य वर्ग पुस्तकालय में अलग होना चाहिए। तो आपके पास आपके आवेदन में एक वास्तविक अलगाव अवधारणा लागू होगी।

बेशक, यदि आपका कोर (व्यवसाय) आपका एप्लिकेशन (एपीआई/वेबसाइट) है, तो व्यवसाय नियम आपके एमवीसी कक्षाओं में लागू किए जाएंगे। लेकिन भविष्य में यदि आप एक नया ऐप विकसित करना चाहते हैं और कुछ व्यवसाय नियम समान हैं, तो मुझे लगता है कि आपको दोनों अनुप्रयोगों में लागू एक ही तर्क को बनाए रखने के लिए बहुत सी समस्याएं होंगी।

5

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

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

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

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

परिभाषा के अनुसार, एन-स्तरीय आर्किटेक्चर में, प्रस्तुति स्तर केवल व्यापार तर्क परत के साथ संवाद करने में सक्षम होना चाहिए, इसलिए यह मानना ​​चाहिए कि किसी भी एमवीसी घटक केवल व्यापार तर्क परत के साथ संवाद कर सकते हैं।

यदि आप ऐसे एप्लिकेशन का निर्माण कर रहे हैं जिसमें प्रेजेंटेशन शामिल नहीं है, और इस प्रकार प्रेजेंटेशन परत नहीं है, तो आपको एमवीसी पैटर्न से खुद को चिंता नहीं करनी चाहिए। हालांकि, आप अभी भी अपने आवेदन को कई स्तरों में विभाजित कर सकते हैं और इस प्रकार एन-स्तरीय डिज़ाइन का पालन कर सकते हैं भले ही कोई प्रस्तुति परत शामिल न हो।

2

आम तौर पर, व्यापार तर्क किसी भी एमवीसी प्लेयर में नहीं रहना चाहिए; यह केवल आपके नियंत्रक कार्यों द्वारा उपभोग किया जाना चाहिए।

जैसा कि कई ने उल्लेख किया है, क्लाइंट अज्ञेयवादी, पुन: प्रयोज्य घटकों के सेट के रूप में व्यवसाय तर्क होस्ट करने के लिए लाइब्रेरी बनाना सर्वोत्तम है।

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

स्टैंड स्टैंड अकेले असेंबली (या असेंबली) में हमारे व्यापार तर्क को सारणी ने वर्षों से हमें अच्छी तरह से सेवा दी है। हमारे व्यापार तर्क को तब भी किसी भी .NET प्रौद्योगिकी (एएसपी.नेट एमवीसी/एपीआई/कोर, डब्ल्यूपीएफ, विन फॉर्म, डब्ल्यूसीएफ, यूडब्ल्यूपी, डब्ल्यूएफ, कंसोल इत्यादि) द्वारा उपभोग किया जा सकता है।

इसके अतिरिक्त, हम .NET MVC फ्रेमवर्क पर हमारी निर्भरताओं को कम करने के लिए व्यवसाय नियम और सत्यापन तर्क को संभालने के लिए हमारे मध्य स्तर को पसंद करते हैं। उदाहरण के लिए, हम .NET MVCs सत्यापन सहायताकर्ताओं का उपयोग करने से बचते हैं और इसके बजाय अपने आप पर भरोसा करते हैं। यह एक और कारक है जो हमें किसी भी .NET प्रौद्योगिकी से आसानी से हमारे व्यापार तर्क का उपभोग करने की अनुमति देता है।

तार्किक रूप से हमारे बीच स्तरीय इस तरह की अनुमति दी हमें आसानी से इस भौतिक वास्तुकला प्राप्त करने के लिए डिजाइनिंग की है:

enter image description here

यह Peasy.NET के साथ लिखा गया था, और पिछले कुछ वर्षों में अच्छी तरह से हमें सेवा की है। वास्तव में वास्तव में हमने इसे स्रोत खोलने का फैसला किया।

यदि कोई भी हमारे मध्य स्तर की तरह दिखता है, तो उत्सुक है, यहां क्लाइंट अज्ञेयवादी, व्यापार परत का sample है। यह कई .NET क्लाइंट्स (एएसपी.नेट एमवीसी, वेब एपीआई, और डब्ल्यूपीएफ) द्वारा खपत का प्रदर्शन भी करता है।

आशा इस कोई मदद करता है!

संबंधित मुद्दे