में बिजनेस नियम कहां हैं अब सभी एमवीसी के बारे में बात कर रहे हैं, मुझे पता है कि व्यापार नियमों को संबोधित नहीं किया जा रहा है। 3-स्तरीय वास्तुकला के पुराने दिनों में, व्यापार नियम मध्यम परत में थे। वे नए एमवीसी में कहां गिरते हैं?एमवीसी
पहले ब्रश पर, मैं कहूंगा कि वे मॉडल में हैं। MVC Entry on Wikipedia सहमत है: "एमवीसी में, मॉडल आवेदन की जानकारी (डेटा) और डेटा में हेरफेर करने के लिए उपयोग किए जाने वाले व्यावसायिक नियमों का प्रतिनिधित्व करता है। आखिरकार, 'व्यवसाय नियम' से हमारा मतलब कार्यात्मक एल्गोरिदम और तर्क है जो उस डोमेन को एन्कोड करता है जिसमें आपका एप्लिकेशन इनपुट/आउटपुट संबंधित तर्क के विपरीत है। ये कोर बिजनेस-संबंधी तर्क उपयोगकर्ता को प्रदर्शित किए जा रहे कार्यों (जो दृश्य का डोमेन है) या उपयोगकर्ता इनपुट (जिसे मुख्य रूप से नियंत्रक द्वारा प्राप्त किया जाता है) के आधार पर नहीं बदला जाना चाहिए।
मेरे अनुभव में, सॉफ्टवेयर विकास प्रक्रिया के दौरान इस तरह के प्रश्न पूछने से बहुत खुलासा हुआ है: हमें कुछ लोगों ने 'व्यवसाय नियम' माना था, लेकिन कुछ और होने के लिए बाहर निकला। यदि यह एक वास्तविक व्यापार नियम नहीं है, तो यह मॉडल से संबंधित नहीं हो सकता है।
मॉडल हालांकि एमवीसी प्रोजेक्ट में नहीं होना चाहिए और इसमें किसी विशेष यूआई तकनीक पर निर्भरता नहीं होनी चाहिए। – Andy
एक विकिपीडिया Article से एक उद्धरण:
MVC अक्सर वेब अनुप्रयोगों, जहां दृश्य वास्तविक HTML पेज है में देखा जाता है, और नियंत्रक कोड है कि गतिशील डेटा बटोरता और HTML के भीतर सामग्री उत्पन्न करता है। अंत में, मॉडल वास्तविक सामग्री द्वारा प्रस्तुत किया जाता है, आमतौर पर डेटाबेस में या एक्सएमएल नोड्स, में संग्रहीत किया जाता है और व्यापार नियम जो उस सामग्री को उपयोगकर्ता क्रियाओं के आधार पर परिवर्तित करता है।
वह एमवीसी नहीं है। एमवीसी कोड व्यवस्थित करने के बारे में है। सभी गतिशील वेबपृष्ठ आपकी परिभाषा के अनुसार एमवीसी होंगे। –
क्या कोई कारण है कि आप एमवीसी और एनटीयर मिश्रण क्यों नहीं कर सकते? हमारा आवेदन बस यही करता है। हमारे नियंत्रकों का उपयोग डेटा सत्यापन के लिए किया जाता है और यह तय करता है कि कौन सा बिजनेस लेयर कॉल करना है।
OurApp.Web - Asp.net MVC परियोजना
OurApp.Business - व्यवसाय लेयर लाइब्रेरी
OurApp.DataAccess - डेटा स्तर लाइब्रेरी
OurApp.Entities - मूल रूप से सभी 'मॉडल' सभी परतों द्वारा साझा
मुझे यह दृष्टिकोण पसंद है। दुर्भाग्य से, मुझे लगता है कि कई वेब ढांचे इस छलांग को असहज बनाते हैं। किसी बिंदु पर आपको अपनी व्यावसायिक परत में सहायक वस्तुओं की आवश्यकता हो सकती है जो किसी भी डेटाबेस टेबल/लगातार भंडारण के अनुरूप नहीं है - कुछ ऐसा जो कि मैंने देखा है कि प्रत्येक मॉडल वर्ग एक आधारभूत चीज है। उस बिंदु पर आप सोचते हैं, मैं इस कोड को कहां रखूं? – Koobz
व्यापार नियम हमेशा मॉडल में रहते हैं। मॉडल थोड़ा सा है कि आप एक पूरी तरह से अलग यूआई के साथ पुन: उपयोग कर सकते हैं। दृश्य स्पष्ट रूप से यूआई विकल्पों पर पूरी तरह से निर्भर है और नियंत्रक को मॉडल से डेटा लेना है और इसे प्रस्तुत करने के लिए दृश्य को बताना है।
दृश्य में व्यापार तर्क डालना बुरा है क्योंकि यह प्रस्तुति के लिए संरचना से संबंध रखता है।
नियंत्रक में व्यावसायिक तर्क डालना खराब है क्योंकि यह मॉडल और सर्वर द्वारा बनाए गए डेटा के बीच आपके व्यापार डोमेन को विभाजित करता है।
कारण आप कभी भी एमवीसी पता "बिजनेस रूल्स" नहीं देखते हैं कि एमवीसी एक और प्रेजेंटेशन पैटर्न है। यह आपके आवेदन को व्यवस्थित करने के तरीके पर केंद्रित है। मॉडल, उदाहरण के लिए, एक प्रेजेंटेशन मॉडल के रूप में सोचा जा सकता है। आपके आवेदन का मॉडल, जिसे दृश्य तब प्रस्तुत करता है।
हालांकि, प्रस्तुति मॉडल बनाने के लिए, आपको आम तौर पर अपने डोमेन मॉडल पर जाना होगा जहां आपका सभी व्यावसायिक तर्क रहता है। उस बिंदु पर, एमवीसी यह निर्धारित नहीं करता है कि वह कोड शारीरिक रूप से कहाँ रहता है। क्या यह एक और स्तर पर है? एमवीसी परवाह नहीं है।
यह स्वीकार्य उत्तर –
आप लोग गलत हैं व्यवसाय नियम नियंत्रक के भीतर रहते हैं, मॉडल नहीं ...
कोई तर्क है? – Kamarey
यह टिप्पणी सिर्फ सादा गलत है। नियंत्रक उस एप्लिकेशन का एक तकनीकी हिस्सा है जो डेटा प्रवाह को व्यवस्थित करता है और मॉडल और दृश्य में क्रियाओं को ट्रिगर करता है। एक ठेठ पीसी अनुप्रयोग में नियंत्रक माउस घटनाओं, कीस्ट्रोक और इसी तरह की चीजों से संबंधित है। –
व्यवसाय नियम मॉडल में होना चाहिए, नियंत्रक नहीं। नियंत्रक और दृश्य प्रस्तुति परत का हिस्सा हैं।
मॉडल डोमेन के संस्थाओं और कार्यक्षमता ..
नियंत्रक केवल मॉडल और मानचित्रण पर इन /, उपयोगकर्ता इनपुट और अनुरोधों लेने कार्रवाईयों के लिए एक प्रबंधक है कि प्रस्तुति परत में विचारों का प्रतिनिधित्व करता है। नियंत्रक केवल मध्यस्थ नहीं है, दृश्य या नियंत्रक मॉडल पर कार्य कर सकता है।
मुझे लगता है कि बहुत से लोग आदर्श रूप से "डेटाबेस मॉडल" के रूप में मॉडल के बारे में सोचते हैं, यही कारण है कि व्यवसाय नियमों में कोई जगह नहीं लगती है। यदि इसके बजाय, आप वास्तविक दुनिया से कुछ के अनुकरण के रूप में मॉडल देखते हैं, तो यह स्पष्ट है कि व्यापार नियम मॉडल के उतने ही हिस्से के रूप में हैं जो वे छेड़छाड़ करते हैं। –
मुझे लगता है कि यह समस्या परिभाषा का विषय है। ऐसा लगता है कि आवश्यक क्रम में स्क्रीन पेश करने के लिए तर्क एक नियंत्रक मुद्दा है और मैंने कुछ परियोजनाओं को देखा है जो आदेश निर्धारित करने के लिए नियम इंजन का उपयोग करते हैं और उपयोगकर्ता से आवश्यक इनपुट क्या है। यह व्यवसाय नियमों के समान नहीं है।
मुझे विश्वास है कि ओपी व्यापार तर्क के बारे में बात कर रहा है जो मॉडल से संबंधित है। –
यह एक बेहद पोस्ट किया गया सवाल है, लेकिन मुझे नियमों के भंडार पसंद हैं जो किसी भी आवेदन के किसी भी हिस्से से पूरी तरह से स्वतंत्र हो। एक से अधिक अनुप्रयोग, एक व्यापार स्तर के कई कार्यान्वयन, एक व्यापार नियम भंडार के एक स्थिर प्रतिपादन तक पहुंचने में सक्षम होना चाहिए। इस तरह के सरल अलगाव निर्णय डेस्कटॉप से माइग्रेशन करते हैं -> वेब, उदाहरण के लिए, तुच्छ।
मेरे आर्किटेक्चर में, देखें -> मॉडल -> नियंत्रक -> व्यापार श्रेणी -> नियम रिपोजिटरी, यानी नियंत्रक व्यापार स्तर/परत द्वारा प्रस्तुत किए गए मोटे डेटा तक पहुंचता है, इसे मॉडल में खिलाता है जो इसे प्रस्तुत करने योग्य में मालिश करता है फॉर्म, और दृश्य निष्क्रिय रूप से प्रदर्शित करता है। व्यापार स्तर, जो कि किसी भी प्रेजेंटेशन प्रारूप में पुनः उपयोग करने योग्य है, के पास निहित नियमों के साथ एक उपप्रणाली के लिए स्पष्ट नियम और पहुंच होगी। डिजाइन द्वारा, प्रत्येक घटक इसके ऊपर एक घटक के विवरण से अनजान है।
तो? Quicksort 46 साल पुराना है और अभी भी इस्तेमाल किया जा रहा है। महत्वपूर्ण बात यह है कि यह बहुत अच्छी तरह से काम करता है। –
मैंने कुछ साल पहले एक ही चीज़ देखी थी। ऐसा लगता है जैसे ही मैंने इसे सीखा, मैंने देखा हर जगह पॉप अप करना शुरू कर दिया। –