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