वसा मॉडल / पतली नियंत्रक बनाम सेवा परत [बंद]

Question

मैं कई वर्षों से एंटरप्राइज़ एप्लिकेशन का उपयोग कर रहा हूं। नेट मेरे ऐप्स में आमतौर पर एक डोमेन मॉडल होता है जिसमें इकाइयां होती हैं जो SQL DB तालिकाओं में मैपिंग करती हैं। मैं एक रिपॉजिटरी पैटर्न, डिपेंडेंसी इंजेक्शन और एक सेवा परत का उपयोग करता हूं।

हाल ही में हमने एमवीसी 3 परियोजनाओं पर काम करना शुरू किया और हमने तर्क दिया कि किस तर्क को रखा जाए। मैं पतली कंट्रोलर / एफएटी मॉडल आर्किटेक्चर के साथ आया और सोच रहा था कि सर्विस लेयर कैसे फिट होगी

विकल्प 1 - मॉडल सेवाओं से बात करता है

नियंत्रक पतला है, मॉडलों पर कॉल के तरीके। मॉडल "जानते हैं" डीबी से खुद को कैसे लोड करें और रिपॉजिटरी या सेवाओं से बात करें। Eg CustomerModel में लोड (id) विधि है और ग्राहक और कुछ बाल वस्तुओं जैसे GetContracts () को लोड करता है।

विकल्प 2 - नियंत्रक सेवाओं से बात करता है

नियंत्रक सेवाओं को मॉडल ऑब्जेक्ट को पुनः प्राप्त करने के लिए कहता है। लोडिंग / स्टोरेज आदि का तर्क सर्विस लेयर में है। मॉडल केवल डेटा के साथ एक शुद्ध इकाई मॉडल है।

विकल्प 1 एक बेहतर विकल्प क्यों होगा, खासकर जब हम उद्यम के बारे में बात करते हैं, तो मेरा अनुभव मुझे अलग-अलग चिंताओं को बताता है, मॉडल और नियंत्रकों को जितना संभव हो उतना पतला रखने और विशेष सेवाएं प्रदान करने के लिए व्यवसाय तर्क (imcl। DB इंटरैक्शन) करता है।

सभी सलाह और अच्छे संसाधनों के संदर्भ के लिए धन्यवाद।

Answer 1

यह सब आपके आवेदन की मंशा और आवश्यकताओं पर निर्भर करता है।

उस ने कहा, यहां "मध्य पैमाने" (स्थानीय रेस्तरां नहीं, और ट्विटर / फेसबुक) वेब अनुप्रयोगों के लिए मेरा सुझाव है।

1. लीन डोमेन मॉडलिंग

   सूखी POCO शैली की वस्तुएं, जो आपके वेब एप्लिकेशन के MVC आर्किटेक्चर से अनभिज्ञ हैं, जो आपके विशेष कार्यान्वयन से यथासंभव कम ही रहती हैं। बाहरी लाइब्रेरी यहां तक ​​कि बाहरी एप्लिकेशन में उपयोग के लिए क्लास लाइब्रेरी रीपैक-सक्षम हैं, WCF वेब सेवा के माध्यम से REST API कहें )।

   MVC में "मॉडल" का सबसे सटीक मतलब है कि नियंत्रक जिस मॉडल से अवगत है और इस प्रकार वह मॉडल जो व्यू के लिए अभिप्रेत है ।

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

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

2. मजबूत सेवा परत

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

   मेरे व्यक्तिगत व्यवहार में, मैं डेटा स्तर पर दोनों सेवाओं को कोड करता हूं, जिसे मैं POCO ऑब्जेक्ट्स (दृढ़ता यांत्रिकी, निम्न स्तर की मान्यता, आदि) के मेरे व्यवहार मॉडलिंग और उच्च स्तरीय सेवाओं (व्यवसाय / वर्कफ़्लो फ़ंक्शन) के करीब मानता हूं। MVC यांत्रिकी।

3. लीन कंट्रोलर्स

   मैं यह सुनिश्चित करता हूं कि मेरा नियंत्रक केवल कोच है , इसमें न तो नाटक (सेवाएं) या खिलाड़ी (इकाई मॉडल या दृश्य मॉडल) है, लेकिन बस यह तय करता है कि कौन किस स्थिति में खेलता है और क्या खेल बनाता है। मेरे नियंत्रक दो काम करते हैं:

   1. इकाई / डोमेन मॉडल के साथ सहभागिता करने वाली कॉल सेवाएँ

   2. उपयुक्त दृश्य के लिए एक दृश्य मॉडल तैयार करें।

   यहां तक ​​कि प्रमाणित / अधिकृत नियंत्रक क्रियाएं इंजेक्शन सेवाओं / विशेषताओं के माध्यम से की जाती हैं।

---

संपादित करें 1:

ध्यान रखें, इसका मतलब यह नहीं है कि आपका एंटिटी / डोमेन मॉडल एनीमिक है या होना चाहिए। ORM, रिपॉजिटरी और कारखाने, सत्यापन या राज्य यांत्रिकी का स्वागत है। यह केवल मध्यम पैमाने के अनुप्रयोगों के लिए, जिसका अर्थ मॉडल MVC में का प्रतिनिधित्व करता है अपने दृश्य के लिए रवाना सौंपने के लिए मॉडल नियंत्रक के लिए, ।

उम्मीद है कि यह बिंदु फाउलर प्रेरितों को शांत करेगा जो एनीमिक मॉडल को एक विरोधी पैटर्न मानते हैं । एक ही समय में, यह है OOP की तुलना में ज्यादा प्रक्रियात्मक कोण को प्रतिबिंबित जहां यह अधिक शुद्ध है मॉडलिंग की कक्षाओं में व्यवहार शामिल करने के लिए।

कोई "अंतिम सत्य" नहीं है, लेकिन इस पैटर्न का उपयोग करने से आपको अपने अनुप्रयोगों के निर्माण, परीक्षण और तैनाती में आसानी होगी - जबकि पुन: प्रयोज्य और मापनीयता को बनाए रखना।

---

संपादित करें 2:

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

---

संपादित करें 3:

मैं यह नोट करना चाहता था कि यह स्पष्टीकरण और सलाह ASP.Net जैसे सर्वर-साइड MVC आर्किटेक्चर के संदर्भ के लिए है, नॉटआउट या बैकबोन जैसे क्लेंट-साइड फ्रेमवर्क के लिए।

Comments

यह लगभग वही डिज़ाइन पैटर्न है जिसका उपयोग मैं नियंत्रक को छोड़कर रिपॉजिटरी का ज्ञान नहीं करता हूं। नियंत्रक केवल उन सेवाओं के साथ इंटरैक्ट करता है जो बदले में रिपॉजिटरी के साथ बातचीत करते हैं।

— लेस्टर

@ लेस्टर I ने इसे स्पष्ट करने के लिए संपादन किया। समय का 95% मेरा भी नहीं है, विचार यह है कि सेवाएं करते हैं। छोटे ऐप्स पर यह ओवरकिल हो सकता है, लेकिन इसका अच्छा अभ्यास किसी को भी और आईओसी कंटेनर के साथ बनाए रखने के लिए बहुत आसान है

— one.beat.consumer

+1 @ one.beat.consumer: यह वही दृष्टिकोण है जो मैं अपनी परियोजनाओं पर लेती हूं ... कभी-कभी नियमों के बारे में बहुत शुद्धतावादी होने के कारण अतिव्यापी समाधान हो जाते हैं, और आप वास्तविक विश्व सिद्ध समाधान से अधिक लाभ प्राप्त करने का अनुभव कर सकते हैं पूरी तरह से GOF पैटर्न का पालन नहीं करता है

— themarcuz

MVC में @ivowiblo मॉडल जो भी डेटा मॉडल है, आपका नियंत्रक प्रीप्स है और व्यू को पास करता है। यही कारण है कि आपका 'एप्लीकेशन मॉडल' (डोमेन मॉडल, मॉडल लेयर, जो भी आप-लेबल-यह) एमवीसी पुस्तकालयों से पूरी तरह से अनभिज्ञ हो सकता है, यहां तक ​​कि एक अलग से वितरित प्रणाली पर आपके समाधान के बाहर भी मौजूद है। MVC में एक अनुरोध नियंत्रक को बस रूट किया जाता है। नियंत्रक एक दृश्य मॉडल (प्रस्तुति परत के लिए डेटा) को इकट्ठा करता है। कि मॉडल एक ही instantiated वस्तु आप हो सकता है आपके हठ यांत्रिकी में, गरीब अभ्यास का इस्तेमाल किया है, लेकिन यह तो है , की अनुमति दी है, जिसका अर्थ वहाँ कोई विशेष परिभाषा है।

— one.beat.consumer

एमवीसी में "मॉडल" को ध्यान में रखते हुए

— लुइज़ डेमिम

Answer 2

इससे पहले कि हम आगे बढ़ें और चर्चा करें कि आपको सब कुछ कहां रखना है। खैर, अगर आप पैटर्न का पालन करना चाहते हैं। अन्यथा अब आप पढ़ना बंद कर सकते हैं।

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

MVC

मॉडल कुछ भी हो सकता है। यह एक webservice, आपकी रिपॉजिटरी, आपकी सेवा कक्षाएं या बस आपके डोमेन मॉडल हो सकते हैं। मॉडल वह सब कुछ है जिसका उपयोग आपको आवश्यक जानकारी प्राप्त करने के लिए किया जाता है। "मॉडल" को केवल एक वस्तु के बजाय एक परत के रूप में मानें।

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

देखें दृश्य केवल वही प्रस्तुत करना चाहिए जो उपयोगकर्ता देखता है।

ध्यान दें कि आपको मॉडल को व्यू मॉडल के साथ भ्रमित नहीं करना चाहिए। Microsoft को वास्तव में "मॉडल" फ़ोल्डर का नाम "ViewModels" रखना चाहिए क्योंकि यह वही है जो वे हैं। मैं सीधे विचारों में "मॉडल" से जानकारी का उपयोग नहीं करूंगा। ऐसा करने में विफलता का मतलब होगा कि यदि दृश्य बदल गया है और दूसरे तरीके से आपको मॉडल बदलना होगा।

उत्तर

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

एक एकल नियंत्रक क्रिया "मॉडल" के लिए एक या कई कॉल का उपयोग कर सकती है जो दृश्य द्वारा आवश्यक जानकारी को इकट्ठा करने में सक्षम हो।

इसका मतलब है कि जब आप एक आवेदन प्राप्त करना चाहते हैं जो आपके लिए दूसरा विकल्प सबसे सही है जिसे बनाए रखना और बढ़ाना आसान है।

ध्यान दें कि एक सेवा परत की आवश्यकता नहीं हो सकती है। आप OR / M को सीधे नियंत्रकों से कॉल कर सकते हैं। लेकिन अगर आप खुद को डुप्लिकेटिंग कोड पाते हैं या वसा नियंत्रक प्राप्त करते हैं, तो तर्क को एक सेवा स्तर पर ले जाएं। कुछ भी नहीं लेकिन नियंत्रक उस परिवर्तन से प्रभावित होगा जब से आप उचित दृश्य मॉडल का उपयोग कर रहे हैं।

Comments

मेरी इच्छा है कि ASP.NET MVC को इसके स्थान पर ASP.NET मॉडल व्यू व्यू कंट्रोलर नाम दिया गया है। यह एक भयानक नाम होगा, लेकिन कम से कम यह इसका सही अर्थ

— बताएगा

ASP.NET MVC का उपयोग करने के बाद भी मुझे अहसास हुआ कि उस मॉडल का मतलब मॉडल को देखना नहीं था।

— लेस्टर

@ one.beat.consumer: मॉडल के बारे में मेरी बात यह थी कि यह कुछ भी हो सकता है। यह सिर्फ एक परत है। इसे बनाएं क्योंकि यह एप्लिकेशन के लिए फिट है। मैंने इसे ऐसे ही रखा है क्योंकि बहुत से लोग सोचते हैं कि ASP.NET MVC में मॉडल व्यू मॉडल है या VM और मॉडल समान है।

— ९

मुझे लगता है कि मैं प्रश्न को संबोधित करता हूं। customerModelजैसे ही वह प्रश्न के बारे में बात करता है मेरी व्याख्या एक दृश्य मॉडल है। अगर वह समझता है कि ऐसा नहीं है तो इसका उत्तर अधिक स्पष्ट है।

— jgauffin

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

— one.beat.consumer

Answer 3

विकल्प 1: आप सोच सकते हैं कि मॉडल == सेवा। मॉडल व्यवसाय की परत भी है।

विकल्प 2 एक एनीमिक डोमेन मॉडल विरोधी पैटर्न है। http://en.wikipedia.org/wiki/Anemic_domain_model

Comments

ध्यान रखें कि कुछ को एक विरोधी पैटर्न कॉल करने के लिए कुछ और संदर्भ की आवश्यकता है! बहुत सारे एप्लिकेशन को एक डोमेन मॉडल की आवश्यकता नहीं होती है, क्योंकि वे जो सबसे ज्यादा काम करते हैं, वह सीआरयूडी ऑपरेशन हैं।

— रूकियन

डोमेन मॉडल सिर्फ एक "मेटाडेटा" वाला डेटा है, यदि आपके पास मेटाडेटा नहीं है, तो ठीक है। मैंने "एंटी-पैटर्न" शब्द हटा दिया क्योंकि आप उस हिस्से पर सही हैं। मुझे वास्तव में स्वीकृत जवाब पसंद है और मेरी खुद की जगह टिप्पणी होनी चाहिए थी।

— इमरे एल

Answer 4

विकल्प 2 जिसे फैट स्टूपिड अग्ली कंट्रोलर्स आर्किटेक्चर ( इस अभिव्यक्ति के लेखक के संदर्भ ) के रूप में वर्णित किया गया है । यह समाधान आम तौर पर एमवीसी भावना के खिलाफ है क्योंकि यह चिंताओं को अलग करता है।

Comments

public ActionResult FetchApple() { return View(_groceryService.GetApple("Granny Smith")); }बहुत दुबला है अगर तुम मुझसे पूछो।

— one.beat.consumer 18

उस FSUC लेख के बारे में मेरी पढाई उपर्युक्त विकल्प 2 से मेल नहीं खाती। एफएसयूसी लेखक द्वारा प्रदान किए गए उदाहरण में एक सेवा परत का उपयोग नहीं दिखाया गया है जहां तर्क देने वाले सभी आदेशों को समझाया जाता है। इसके बजाय, यह दिखा रहा है कि नियंत्रक को व्यावसायिक तर्क के साथ लोड किया गया है। और व्यापार तर्क की पुन: प्रयोज्यता, एक नियंत्रक में होने के कारण, अब खो गई है।

— मार्वो