यदि कोई नियंत्रक बहुत मोटा हो जाता है और मॉडल इंस्टेंटेशन जोड़ना शुरू कर देता है, तो सेवा परत का उपयोग किया जा सकता है।
यदि मैं सिर्फ एक सेवा वर्ग के अंदर तर्क को लपेटता हूं, तो मुझे एक / दो विधियों के साथ सेवाओं का एक गुच्छा मिलेगा। यह एक कोड गंध की तरह लगता है। इस बारे में कोई सर्वोत्तम अभ्यास?
क्या एक सेवा मॉडल को त्वरित कर सकती है?
यदि कोई सेवा मॉडल का तुरंत प्रसारण करती है, तो सेवाओं का परीक्षण नहीं किया जा सकता है। उन्हें केवल एकीकरण परीक्षणों द्वारा कवर किया जा सकता है?
जवाबों:
'SOLID' में 'I' का मतलब इंटरफ़ेस अलगाव है। इस सिद्धांत का पूरा विचार बड़े इंटरफेस को छोटे लोगों में विभाजित करना है, अधिक मॉड्यूलर। एमवीसी सेवा में आमतौर पर एक इंटरफ़ेस होता है जो नियंत्रक पर निर्भर करेगा। आप नहीं चाहते कि आपके नियंत्रक उस सेवा के ठोस कार्यान्वयन के बारे में जानें। इसलिए, एक या दो तरीकों वाली सेवाओं का एक समूह होना अच्छी बात है।
सेवाएँ सामान्य रूप से बड़े अनुप्रयोगों या सीधे छोटे अनुप्रयोगों में डोमेन मॉडल में DTO लौटाती हैं। डीटीओ का सामान्य रूप से अधिक काम होता है, लेकिन चिंताओं का बेहतर पृथक्करण। विशिष्ट प्रवाह है:
मैपिंग को मैन्युअल रूप से किया जा सकता है, लेकिन ज्यादातर डेवलपर्स ऑटो मैपिंग जैसे ऑटो मैपिंग फ्रेमवर्क का उपयोग करना पसंद करते हैं क्योंकि हमें प्लंबिंग कोड लिखना पसंद नहीं है और हम काफी आलसी हो सकते हैं :-)
http://en.wikipedia.org/wiki/Interface_segregation_principle
https://github.com/AutoMapper/AutoMapper
डीटीओ और डोमेन मॉडल के उपयोग के बारे में स्टैकओवरफ्लो पर कई चर्चाओं में से एक: /programming/2680071/dto-or-domain-model-object-in-the-view-layer
MVC मॉडल में, केवल एक DTO या प्रबंधक / सेवाओं का सेट नहीं है, यह उन अवधारणाओं का प्रतिनिधित्व करने के लिए है जो आपका एप्लिकेशन मॉडलिंग कर रहा है। आप इसे संपूर्ण डोमेन या राज्य और व्यवहार सहित व्यावसायिक तर्क के रूप में सोच सकते हैं। अब यह देखते हुए कि हम जानते हैं कि नियंत्रक का उद्देश्य थोड़ा स्पष्ट हो जाता है। यह काम बस मॉडल पर आदेशों का अनुवाद करने के लिए है और परिणाम वापस विचारों पर। यह आमतौर पर ViewModels के रूप में किया जाता है जो MVC में मॉडल के साथ अलग लेकिन अक्सर भ्रमित होते हैं।
यदि आपके पास एक अच्छी तरह से परिभाषित मॉडल नहीं है, तो आप उस बिंदु पर पहुंच गए होंगे, जहां उस तर्क के अधिकांश अब खुद नियंत्रकों में रहते हैं। इस बिंदु पर अपने नियंत्रकों के आकार को कम करना शुरू करने के लिए आप इस तर्क को प्रबंधक या सेवा वस्तुओं में वापस खींचना शुरू कर सकते हैं। ये सेवाएं आमतौर पर वस्तुओं की तरह डीटीओ / इकाई पर लौटती हैं और काम करती हैं। फिर नियंत्रक इन सेवाओं और दृश्य मॉडल के बीच मानचित्रण परत बन जाता है। मानचित्रण के कुछ अच्छे सुझावों के लिए इस लेख पर एक नज़र डालिए मित्र मित्रों को AutoMapper का उपयोग करने की अनुमति नहीं है ।
आपके प्रश्नों के लिए, पहले वाला आपके अनुप्रयोगों पर बहुत कुछ निर्भर करता है। आपको अपने नियंत्रकों से तर्क निकालने के बाद जिस तरह से और अधिक स्पष्ट हो जाना चाहिए, उसके साथ आपको फिर से काम करना होगा। परीक्षण के लिए सेवाओं के अंदर कोई समस्या झटपट मॉडल नहीं है, लेकिन अगर आपको यह मुश्किल लगता है तो यह शायद एक संकेत है कि आपको एक ही जिम्मेदारी के साथ सेवा को छोटे भागों में तोड़ने की जरूरत है।
नियंत्रकों को केवल मॉडल (जहां व्यापार तर्क होता है) में कॉल होना चाहिए और उन कॉल के आधार पर दृश्य (सूचना या त्रुटि संदेशों की वस्तुओं) के लिए डेटा असाइन किया जाता है इसलिए नियंत्रक बहुत जटिल पृष्ठ के लिए भी बहुत छोटा होगा, यदि नियंत्रक अभी भी हो बहुत बड़ा हो जाता है आपको यह सोचना चाहिए कि शायद उस पृष्ठ को और अधिक पृष्ठों में विस्तारित किया जाना चाहिए।
फिर भी मॉडल काफी बड़ा हो सकता है ... मैंने जो समाधान पाया वह नियंत्रक के अंदर एक चर था जो बताता है कि किस मॉडल को लोड करना है और विशिष्ट कार्यों के लिए मैं विशिष्ट मॉडल को लोड करता हूं।
मॉडल-व्यू-कंट्रोलर मॉडल को इस तरह से साफ मानने की कोशिश करें:
मुझे तर्क के प्रदर्शन के लिए सेवाएं वास्तव में मददगार लगती हैं, जिन्हें एक से अधिक नियंत्रक द्वारा निष्पादित करने की आवश्यकता हो सकती है या जो कि नियंत्रक के अंग होने के लिए पर्याप्त विशिष्ट नहीं है, इस तथ्य के अलावा कि यह मेरे नियंत्रकों को बहुत बड़ा और पढ़ने में कठिन है। ।
मैं व्यक्तिगत रूप से 'आ' से असहमत हूं, जब वह कहता है कि "मॉडल (जहां बूसी तर्क खुशी देता है)" चूंकि पूरे कारण से आपके पास नियंत्रकों हैं, मेरी राय में मॉडल को सरल डेटा एब्स्ट्रैक्टर्स होने की आवश्यकता है ताकि नियंत्रक आवश्यक कार्य कर सकें; फिर से सेवाओं को डेटा अमूर्त कार्य में शामिल नहीं होना चाहिए ...
बस यो कह रही है…।