क्या MVC एंटी OOP नहीं है?

61

OOP के पीछे मुख्य विचार एक इकाई में डेटा और व्यवहार को एकीकृत करना है - वस्तु। प्रक्रियात्मक प्रोग्रामिंग में डेटा होता है और अलग से एल्गोरिदम डेटा को संशोधित करता है।

मॉडल-व्यू-कंट्रोलर पैटर्न में डेटा और लॉजिक / एल्गोरिदम को क्रमशः अलग-अलग संस्थाओं, मॉडल और कंट्रोलर में रखा जाता है। एक समरूप OOP दृष्टिकोण में मॉडल और नियंत्रक को एक ही तार्किक इकाई में नहीं रखा जाना चाहिए?

design object-oriented mvc

— m3th0dman
स्रोत

11

उन्हें एक ही तार्किक इकाई में रहने की आवश्यकता क्यों होगी? आपने यह नहीं बताया कि यह लाभप्रद क्यों होगा, या OOP इस व्यवस्था को क्यों निर्देशित करेगा।

— रॉबर्ट हार्वे

26

खैर, व्यापार तर्क मॉडल में जाता है, नियंत्रक नहीं। नियंत्रक वास्तव में केवल एक साथ देखने और मॉडल को एक साथ गोंद करने के लिए है। तो मॉडल में, आपके पास एक ही स्थान पर डेटा और व्यवहार है।

— रॉबर्ट हार्वे

2

क्या? डेटा और व्यवहार को एक साथ एकजुट करना बिल्कुल OOP के बारे में है।

— एंडी

3

OOP इंटरफेस से कार्यान्वयन को अलग करने के बारे में है। इंटरफेस का व्यवहार के साथ अधिक होता है, और डेटा के साथ कार्यान्वयन अधिक होता है (यही वजह है कि डेटा छिप जाता है)। इसलिए OOP डेटा और व्यवहार को एकीकृत करने के बारे में नहीं है, बल्कि उन्हें अलग कर रहा है।

— काज

5

वैसे भी, आप सभी डेटा और व्यवहार को एक वर्ग में रखना नहीं चाहते हैं। ओओपी कार्यक्रम वस्तुओं के ढांचे बनाने के लिए एक से अधिक वर्ग का उपयोग करते हैं। और वैसे भी, अगर कुछ "विरोधी ओओपी" है, तो यह अच्छी बात हो सकती है। ओओपी सभी-सभी अंत नहीं है। OOP नीचे की ओर बेकार है। यह ओओपी पर पहुंचने का समय है।

— काज

44

एमवीसी, सेपरेशन ऑफ़ कॉनर्न्स , एक यूआई आर्किटेक्चर में एक अभ्यास है । यह उस जटिलता को पुष्ट करने का एक तरीका है जो प्रस्तुति में सामग्री से अलग नहीं होने के कारण उपयोगकर्ता इंटरफ़ेस में हो सकती है ।

सिद्धांत रूप में, सभी वस्तुओं में ऐसा व्यवहार हो सकता है जो उनके द्वारा रखे गए डेटा पर काम करता है, और यह कि डेटा और व्यवहार संकुचित रहता है । व्यवहार में, किसी दिए गए OOP ऑब्जेक्ट में तर्क हो सकता है या नहीं हो सकता है जो उसके डेटा से मेल खाता है, या उसके पास कोई तर्क नहीं हो सकता है ( उदाहरण के लिए डेटा ट्रांसफर ऑब्जेक्ट )।

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

लेकिन यह भी कि व्यवस्था सख्त डेटा / व्यवहार संलयन की गारंटी नहीं देती है। केवल डेटा वाले ऑब्जेक्ट्स को केवल लॉजिक वाले अन्य वर्गों द्वारा संचालित किया जा सकता है, और यह OOP का पूरी तरह स्वीकार्य उपयोग है।

मैं आपको एक विशिष्ट उदाहरण देता हूँ। यह थोड़ा विरोधाभास है, लेकिन मान लीजिए कि आपके पास एक Currencyवस्तु है, और वह वस्तु किसी भी उपलब्ध मुद्रा में खुद का प्रतिनिधित्व करने की क्षमता है, जो डॉलर के लिए आंकी गई है। तो आपके पास तरीके होंगे:

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... और वह व्यवहार मुद्रा ऑब्जेक्ट के साथ समझाया जाएगा।

लेकिन क्या होगा अगर मैं मुद्रा को एक खाते से दूसरे खाते में स्थानांतरित करना चाहता हूं, या कुछ मुद्रा जमा करना चाहता हूं? क्या वह व्यवहार मुद्रा वस्तु में भी कूटबद्ध होगा? नहीं, यह नहीं होगा। आपके बटुए का पैसा आपके बटुए से आपके बैंक खाते में स्थानांतरित नहीं हो सकता है; उस खाते को आपके खाते में पहुंचाने में सहायता के लिए आपको एक या अधिक एजेंट (एक टेलर या एटीएम) की आवश्यकता होती है।

ताकि व्यवहार एक में समझाया की जाएगी Tellerवस्तु, और इसे स्वीकार करेंगे Currencyऔर Accountइनपुट के रूप में वस्तुओं, लेकिन यह किसी भी डेटा अपने आप को शामिल नहीं हैं, हो सकता है स्थानीय राज्य (या शायद एक का एक सा छोड़कर Transactionवस्तु) मदद करने के लिए इनपुट वस्तुओं की प्रक्रिया।

— रॉबर्ट हार्वे
स्रोत

और किस इकाई / पैकेज Tellerमें रखा जाना चाहिए ? उन तरीकों Controllerसे जहां से Teller'sतरीकों को बुलाया जाता है या Modelक्योंकि यह व्यापारिक तर्क का हिस्सा है?

— m3th0dman

Tellerमें जाता है Model, हालांकि यह नियंत्रक से बुलाया जा सकता है। यह व्यवसाय डोमेन का हिस्सा है।

— रॉबर्ट हार्वे

मैंने हमेशा सोचा है कि व्यावसायिक नियमों के लिए मॉडल का उपयोग करना MVC को एक अर्ध-प्रभावी पैटर्न बनाता है। वास्तविक एप्लिकेशन के लिए एडेप्टर के लिए मॉडल का उपयोग करना, और नियंत्रक के बीच एडेप्टर और दृश्य के बीच मध्यस्थता करना हमेशा SoC को प्राप्त करने में बहुत अधिक प्रभावी होता है।

— यम मार्कोविच

@YamMarcovic: मुझे यकीन नहीं है कि आपका क्या मतलब है। मॉडल एक पकड़-सभी की तरह है; व्यवहार में, व्यावसायिक नियमों को आमतौर पर अपनी सेवा परत में रखा जाता है, लेकिन यह अभी भी मॉडल का हिस्सा माना जाता है (उदाहरण के लिए, आप एक व्यक्तिगत नियंत्रक विधि के भीतर विशिष्ट व्यावसायिक नियमों को एनकोड नहीं करेंगे)। आप सही हैं कि नियंत्रकों के बीच जाना है।

— रॉबर्ट हार्वे

4

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

— एरिक रेपेन

73

एमवीसी एकल वस्तुओं की तुलना में बहुत अधिक उच्च स्तर पर काम करता है , और वास्तव में तीनों (मॉडल, व्यू और कंट्रोलर) में से प्रत्येक में आमतौर पर कई ऑब्जेक्ट शामिल होते हैं, जिनमें से प्रत्येक में डेटा और व्यवहार दोनों होते हैं।

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

— माइकल बोर्गवर्ड
स्रोत

ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण एब्सट्रैक्शन के स्तर को माप सकता है; उदाहरण के लिए देखें डोमेन संचालित डिज़ाइन के पीछे का कारण जो दिखाई दिया क्योंकि शास्त्रीय स्तरित वास्तुकला ओओपीश नहीं है, बल्कि प्रक्रियात्मक है। यह एमवीसी की तुलना में उच्च स्तर के अमूर्त स्तर पर होता है।

— m3th0dman

6

@ m3th0dman: आप व्यापक, व्यापक सामान्यताओं में बोल रहे हैं। विवरणों के बारे में चर्चा कैसे करें, जैसे कि एमवीसी स्पेगेटी-कोड दुःस्वप्न को समाप्त करता है जो कि Winforms या Webforms है?

— रॉबर्ट हार्वे

3

@ m3th0dman: यह DDD का एक बहुत ही सरल लक्षण वर्णन है।

— माइकल बोर्गवर्ड

1

@RobertHarvey यह सुनिश्चित करने के लिए कि आप MVC क्यों अच्छा है का प्रतिवाद कर रहे हैं क्योंकि यह स्पेगेटी के साथ दूर करता है वास्तव में यहाँ प्रतियोगिता में नहीं है। मैं सहमत हूं लेकिन मैं MVC को प्रक्रियात्मक पैटर्न में भी लागू होते देखना चाहता हूं। इसलिए मुझे लगता है कि यह एक प्रासंगिक सवाल है, या यों कहें- शायद सवाल यह है कि "लोग कितनी बार MVC को प्रक्रियात्मक रूप से लागू करते हैं?"

— जिमी हॉफ

1

@ रॉबर्ट हार्वे प्रश्न का उद्देश्य यह नहीं है कि MVC कितना अच्छा या बुरा है; यह इस तथ्य के बारे में है कि OO सिद्धांतों पर आधारित है या नहीं।

— m3th0dman

71

ओओपी उन वस्तुओं के बीच बातचीत को प्रतिबंधित नहीं करता है जिनमें से प्रत्येक का अपना डेटा और अपना व्यवहार है।

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

— dasblinkenlight
स्रोत

5

+1: मैं आमतौर पर उपमाओं के माध्यम से स्पष्टीकरण को नापसंद करता हूं, लेकिन यह शानदार है।

— माइकल बोरगवर्ड

@ कालेब यह एक उत्कृष्ट बिंदु है, बहुत-बहुत धन्यवाद!

— dasblinkenlight

19

OOP भी चिंताओं के पृथक्करण के बारे में है , जो विभिन्न वस्तुओं में विभिन्न भूमिकाओं / जिम्मेदारियों को अलग करना है।

MVC इन घटकों में अलग हो जाता है:

मॉडल: डेटा और उसके व्यावसायिक तर्क
देखें: डेटा का प्रतिनिधित्व
नियंत्रक: मॉडल और दृश्य के बीच समन्वय।

तो ये जिम्मेदारियां स्पष्ट रूप से अलग हैं और वास्तव में कई संस्थाओं में अलग होना चाहिए।

— मार्को-fiset
स्रोत

यह सच है कि एकल जिम्मेदारी सिद्धांत प्रभावी रूप से OOP का उपयोग करने में सहायक है, लेकिन मुझे लगता है कि यह कहना एक खिंचाव है कि "OOP एकल जिम्मेदारी सिद्धांत के बारे में भी है।" जो पिछड़ा हुआ लगता है।

— कालेब

@ कालेब हाँ, मैं समझता हूँ कि आपका क्या मतलब है। हो सकता है कि इसे पुनःप्रकाशित किया जा सकता है, लेकिन आप इस बिंदु को प्राप्त करते हैं।

— मार्को-फिसेट

18

मॉडल-व्यू-कंट्रोलर पैटर्न में डेटा और लॉजिक / एल्गोरिदम को क्रमशः अलग-अलग संस्थाओं, मॉडल और कंट्रोलर में रखा जाता है।

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

इसे इस तरह से सोचें: यदि वस्तुएं बिना एनकैप्सुलेशन तोड़े हुए डेटा को आगे-पीछे नहीं कर सकती हैं, तो आप वास्तव में केवल एक ही वस्तु रख सकते हैं!

एक समरूप OOP दृष्टिकोण में मॉडल और नियंत्रक को एक ही तार्किक इकाई में नहीं रखा जाना चाहिए?

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

— कालेब
स्रोत

मुझे उम्मीद है कि नियंत्रक के पास तर्क है लेकिन किसी भी राज्य के लिए बहुत कम है। नियंत्रक किस प्रकार की सोच रहे हैं?

— मैथ्यू फ्लिन

1

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

— कालेब

1

@MattFenwick 'स्वाद' के बारे में मेरा यही मतलब है ... वास्तव में आप नियंत्रक में क्या संग्रहित करते हैं और मॉडल में क्या स्वाद और परंपरा है। कोको / कोको टच में, वर्तमान चयन और नियंत्रक में उपयोगकर्ता की प्राथमिकताओं के रूप में ऐसी चीजों को रखना आम है। MVC जैसा कि कुछ वेब फ्रेमवर्क में उपयोग किया जाता है, मॉडल में लगभग सब कुछ डाल सकता है और नियंत्रक में बहुत कम हो सकता है। YMMV।

— कालेब

4

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

— एरिक रेपेन

1

@MattFenwick: बहु-उपयोगकर्ता अनुप्रयोग पर विचार करें। मॉडल और नियंत्रक के बीच की रेखा खींचने के लिए एक स्पष्ट बिंदु यह है कि मॉडल साझा स्थिति को नियंत्रित करता है और स्थानीय स्थिति को नियंत्रित करता है। वर्तमान चयन स्थानीय है, इसलिए यह नियंत्रक में जाता है।

— Jan Hudec

4

एमवीसी एक पैटर्न है जो वस्तुओं को बातचीत करने के लिए एक समझदार तरीका बताता है; यह स्वयं एक मेटा-क्लास नहीं है। उस समय, OO संस्थाओं के व्यवहार और डेटा का वर्णन करने के बारे में है, और कहा कि संस्थाएं कैसे बातचीत करती हैं। यह पूरे सिस्टम को एक बड़े पैमाने पर ऑब्जेक्ट में एकीकृत करने के बारे में नहीं है।

— जोनाथन वेदरहेड
स्रोत

2

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

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

— Superm
स्रोत

2

मॉडल लेयर केवल डेटा नहीं है कंट्रोलर लेयर से अधिक केवल तर्क है।

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

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

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

— माइकल के
स्रोत

2

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

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

MVC OOP के साथ संघर्ष में नहीं है - यह वास्तव में ऑब्जेक्ट ओरिएंटेड प्रिंसिपल्स के एक सही अनुप्रयोग से लिया गया है।

— DJClayworth
स्रोत

0

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

जिस प्रकार मॉडल ऑब्जेक्ट व्यवसाय नियमों को स्थापित करने के लिए डेटा बनाए रखता है, एक नियंत्रक, IMO, को अधिक सामान्य एप्लिकेशन स्टेट डेटा पर निर्भर रहना चाहिए कि ऐप को कैसे व्यवहार करना चाहिए, जैसे उपयोगकर्ता लॉग इन है या उनके पास वैध क्रेडिट है कार्ड डेटा जगह में। मॉडल विधियाँ इन चीज़ों की स्थिति को पहले ही निर्धारित कर लेंगी, लेकिन नियंत्रक के लिए सामान्य ऐप प्रवाह के लिए झंडे को बनाए रखने के लिए यह समझ में आता है कि अगर वे लागू नहीं होते हैं तो व्यापार कैसे चलाया जाता है या डेटा लेन-देन किया जाता है। एक बार जब आप निर्धारित कर लेते हैं कि वे लॉग इन नहीं हैं, तब तक यूज़र स्टेट चेक से मॉडल को परेशान न करें, जब तक कि यह स्पष्ट न हो कि एक और लॉग-इन का प्रयास किया जा रहा है।

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

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

— एरिक रेपेन
स्रोत

0

जैसा मुझे समझ में आया; तर्क घटक आधारित आर्किटेक्चर बनाम ओओपी है। और धार्मिक युद्ध में शामिल हुए बिना, मुझे लगता है कि वे दोनों एक ही बात का वर्णन कर रहे हैं; बस इसे विभिन्न कोणों से देख रहे हैं।

उदाहरण के लिए, OOP / OOD का पूरा बिंदु आपके कोड को अधिक मॉड्यूलर और पुन: प्रयोज्य बनाना है। हाँ?

जो वास्तव में घटक आधारित वास्तुकला का लक्ष्य है। इसलिए वे किसी भी चीज से ज्यादा एक जैसे हैं।

मुझे लगता है कि एमवीसी ओओपी का प्राकृतिक विकास है और मैं इसे कहने की हिम्मत करता हूं; अपनी वस्तुओं को व्यवस्थित करने के लिए एक बेहतर तरीका, चिंताओं और कोड के पुन: उपयोग को अलग करना।

— DJM
स्रोत

मैं कहूंगा कि एमवीसी और कंपोनेंट-आधारित आर्किटेक्चर ऐसे डिज़ाइन पैटर्न हैं जो ओओपी दृष्टिकोण के दायरे से बाहर नहीं हैं जबकि ओओडी / ओओपी केवल एक भ्रम और प्रोग्रामिंग के उपयोग के बारे में सोचा और मैलाकैमिया के स्कूलों के भ्रम और टकराव का एक गुच्छा है। ठीक से निर्माण। चीजों की दो श्रेणियों की तुलना करना वर्गों की तुलना करने के लिए है और जिस कलम का उपयोग आपने वर्गों को आकर्षित करने के लिए किया है।

— एरिक रेपेन

-1

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

इसलिए, मुझे लगता है कि असली सवाल यह है; क्या हम MVC पैटर्न का उपयोग करते समय प्रक्रियात्मक कोड के लिए अधिक प्रवण हैं।

(और हो सकता है कि मुझे सिर्फ कुछ वोट मिले हों?)

— aserwin
स्रोत

-1

MVC के लिए एंटी नहीं है, लेकिन OOP की भी आवश्यकता नहीं है।

क्योंकि नियंत्रकों, जो आमतौर पर वर्गीकृत द्वारा दर्शाए जाते हैं, कोई डेटा नहीं रखते हैं। जिसके लिए शुद्ध कार्य पर्याप्त होंगे।

यदि आप व्यवहार से आगे डेटा को अलग करते हैं, उदाहरण के लिए मान लें कि मॉडल केवल डेटाबेस डेटा पर काम करते हैं, जिसे वे हर बार अपने फ़ंक्शन (जो डेटा हेरफेर के लिए ज़िम्मेदार होता है) को कहा जाता है (उदाहरण के लिए किसी प्रकार का डेटा संग्रहीत करने के लिए) फ़ील्ड) - तब आप मॉडल के लिए भी ऐसा ही कह सकते हैं।

आगे बढ़ते हुए, यदि आप किसी एप्लिकेशन की दृश्य परत लेते हैं और उसे समान रूप से विभाजित करते हैं, तो आप वास्तव में इस निष्कर्ष के साथ समाप्त होंगे कि MVC का OOP से कोई लेना-देना नहीं है, और केवल प्रक्रियात्मक दृष्टिकोण का उपयोग करके किसी भी दर्द के बिना MVC कार्यान्वयन लिखना पूरी तरह से संभव है ।

— luke1985
स्रोत

हाहा, मैं देख रहा हूं कि कुछ लोगों को ** में दर्द हुआ जब तथ्यों का सामना किया गया। ओओपी के साथ खुद का ढांचा बनाने के लिए बहुत प्रयास? खोए समय को बर्दाश्त नहीं कर सकता? सबसे सरल उत्तर सबसे अच्छे हैं।

— luke1985

निश्चित नहीं है कि इस उत्तर में गिरावट क्यों है। वह कह रहा है कि वे संबंधित नहीं हैं, और "विरोधी" नहीं हैं। बहुत सटीक लगता है।

— mwilcox

-3

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

— user123790
स्रोत

क्या यह केवल आपकी राय है या आप इसे किसी तरह वापस कर सकते हैं?

— 11:18