MVC: व्यावसायिक तर्क कहां रखें? [बन्द है]

Question 1

बंद हो गया । यह सवाल राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

4 महीने पहले बंद हुआ ।

इस प्रश्न को सुधारें

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

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

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

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

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

Question 2

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

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

Question 3

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

Question 4

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

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

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

Question 5

मेरी टीम जब webforms (asp.net) से mvc में चली गई, तो उसने अनुसंधान का एक बहुत कुछ किया और निम्नलिखित संरचना के साथ आया। मेरे अनुसार इसके बारे में नहीं कि आवेदन कितना बड़ा या छोटा है। इसके कोड को साफ और स्पष्ट रखने के बारे में।

DALProject

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

BLLProject

AccountsBLL.cs ---> Calls DAL

वेबप्रोजेक्ट

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

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

Question 6

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

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

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

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

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

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

Question 7

सामान्यतया, एमवीसी खिलाड़ियों में से किसी में भी बिजनेस लॉजिक नहीं होना चाहिए; यह केवल अपने नियंत्रक कार्यों द्वारा सेवन किया जाना चाहिए ।

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

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

हमारे व्यापार तर्क को एक स्टैंड असेंबली (या असेंबली) में शामिल करते हुए हमें वर्षों से अच्छी तरह से सेवा दी है। हमारे व्यापार तर्क को तब लगभग किसी भी .NET तकनीक (ASP.NET MVC / API / Core, WPF, Win Forms, WCF, UWP, WF, Console, आदि) द्वारा खाया जा सकता है।

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

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

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

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

आशा है कि यह किसी की मदद करता है!

Question 8

व्यवसाय तर्क आपके मॉडल दृश्य या नियंत्रक में नहीं जाना चाहिए । एक अलग व्यापार तर्क परत होना चाहिए ; इस परत का एकमात्र उद्देश्य आपके व्यावसायिक तर्क को संभालना है। यह SOLID के साथ अधिक है ।

यदि आप अपने व्यापार तर्क को एमवी या सी में डालते हैं, तो आप उस कोड के साथ समाप्त होते हैं जो परीक्षण / पुन: उपयोग करना मुश्किल है।

मॉडल्स में तर्क रखने के बारे में क्या?

यह एक बुरा समाधान है।

आप एक डिपेंडेंसी नर्क में समाप्त हो जाएंगे जहां ऑब्जेक्ट वस्तुओं पर निर्भर करते हैं।

यहां तक कि अगर आपके पास एक मृत सरल कार्य है, तो भी आपको इसे कॉल करने के लिए सभी निर्भरताओं को पूरा करना होगा।

यह बिना किसी कारण के अनावश्यक और अप्रयुक्त डेटा को भी पास कर देगा। यह प्रदर्शन को भी प्रभावित कर सकता है कि यह कितना बुरा हो जाता है।

मुझे यह भी उल्लेख करना चाहिए कि यूनिट परीक्षण एक ** में दर्द बन जाता है क्योंकि आपको एक साधारण फ़ंक्शन का परीक्षण करने के लिए कई वस्तुओं का मजाक उड़ाना पड़ता है।

स्वच्छ संहिता के सिद्धांत लागू होते हैं

कक्षाएं / कार्य केवल वही लेते हैं जो उन्हें काम पाने के लिए आवश्यक है।
यदि संभव हो तो फ़ंक्शंस को 3 पैरामीटर या उससे कम लेना चाहिए
नाम वर्गों / कार्यों / चर को समझदारी से (Microsoft के मानकों का पालन करें)
मॉडल व्यू या कंट्रोलर को बिजनेस लॉजिक न दें

नियंत्रकों

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

Question 9

मेरे पास सामान्य उत्तर यह है कि व्यावसायिक तर्क सामान्य रूप से दो श्रेणियों में फिट होता है:

ऑब्जेक्ट ओरिएंटेड बिजनेस लॉजिक: ऑब्जेक्ट्स (मॉडल में) के रूप में मॉडल किया जाता है, आमतौर पर रिपॉजिटरी के रूप में इंजेक्शन होता है।

प्रक्रियात्मक व्यावसायिक तर्क: एक इंटरफ़ेस के साथ एक सेवा में जाता है जिसे नियंत्रक में इंजेक्ट किया जा सकता है।

नियंत्रक तर्क: तर्क जो नियंत्रित करता है कि कैसे आदेश प्राप्त किए जाते हैं और मॉडल / सेवाओं को पारित किए जाते हैं, फिर उन परिणामों को दृश्य में कैसे पारित किया जाता है।

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

Question 10

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

Question 11

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

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

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

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

Question 12

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

Question 13

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

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

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

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

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

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

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

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

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