2010-01-16 9 views
7

मुझे पहले से ही एमवीपी और एमवीसी के बीच का अंतर पता है। फिर एक आवेदन के एसआरएस के माध्यम से जाने के बाद भी मुझे एक फिक्स में मिलता है जिसे एक को चुनने, लागू करने और एप्लाकेशन आर्किटेक्चर के रूप में पालन करने की आवश्यकता होती है। मेरी समझ के अनुसार मैं एमवीपी चुनूंगा जहां 2 से अधिक जीयूआई से समान व्यवसाय तर्क का उपयोग करने की संभावना है। एक सार्वजनिक (www) और एडमिंग (Winform) भाग के साथ एक आवेदन की तरह। यदि ऐसा नहीं है ... एमवीसी के लिए देखो। क्योंकि मैं फैक्टरी पैटर का अधिक सटीक पालन कर सकता हूं।एमवीपी (मॉडल व्यू प्रेजेंटर) या एमवीसी (मॉडल व्यू कंट्रोलर)

दोस्तों, मैं नहीं जानता कि लेकिन मैं की तरह मैं सिर्फ अंधा शॉट खेलने अगर मैं उन के बीच चयन करने के लिए मिल गया होता लग रहा है। मुझे जानने की जरूरत है। आप पर क्या राय है?

नोट: मैं .net और C# का पालन करता हूं।

उत्तर

17

मेरे मन में मॉडल देखें नियंत्रक पैटर्न के सभी रूपों के लिए मतभेद (MVP, Passive View, Supervising Controller, देखें मॉडल, etc.) काफी सूक्ष्म हैं। यह सब कुछ है जो डेटा को संसाधित करता है और वास्तव में कौन से डेटा लेता है। वे सब एक और बातसे कुछ अलग ही समस्या हल करने की कोशिश कर रहे हैं, और समाधान सभी ऐसा कर इसी तरह से।

Simplistic MVC: 

+-------+  manipulates data 
| Model |<---------------------+ 
+-------+      | 
    |       | 
    | gets data    | 
    v       | 
+------------+ serves data +------+ 
| Controller |------------->| View | 
+------------+    +------+ 

Simplistic MVP: 

+-------+ 
| Model | 
+-------+ 
    |^
    | | get/manipulates data 
    v | 
+-----------+ serve data +------+ 
| Presenter |-------------->| View | 
|   |<--------------|  | 
+-----------+ tell changes +------+ 

वे पाते हैं कि वर्ग पदानुक्रम दोनों में एक ही लग सकता है में इसी तरह कर रहे हैं:

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

यह करता है वास्तव में है कि ज्यादा बात नहीं, क्योंकि वे सभी स्वयं में कोड के टुकड़े को अलग करने तर्क संस्थाओं की सेवा और कोड दोहराव कम करने का एक सिद्धांत पर आधारित हैं। जब तक आप code coupling low रखते हैं, तब तक इसे अंत में अच्छी तरह से काम करना चाहिए। यह केवल तभी महत्वपूर्ण है जब आप अपने आवेदन के आर्किटेक्चर के साथ dogmatically परिणामस्वरूप बनना चाहते हैं।

इसके बारे में व्यावहारिक बनें और वह है क्या अपनी आवश्यकताओं के लिए सबसे अच्छा सूट के बाद से तुम वैसे भी मिश्रण के साथ खत्म हो जाएगा है। दृश्य की ज़रूरतों के आधार पर बदलावों के बीच स्विच करना "काफी" आसान होना चाहिए। SOLID सिद्धांतों का पालन करें और आपको ठीक करना चाहिए। (this about SOLID भी देखें)।

मैं तुम्हें अगर वहाँ MVC या एमवीपी चौखटे हैं पर गौर है कि यह कैसे किया जाता है देखने के लिए सुझाव है।

+0

+ जवाब में ASCII चित्र की प्रशंसा 1..always है। –

+0

खराब: आपकी प्रतिक्रिया काफी व्याख्यात्मक है .. धन्यवाद। – Sumeet

1

मुझे लगता है कि आप यहां सही रास्ते पर हैं। वेब ऐप्स के लिए एक से अधिक जीयूआई और एमवीसी वाले ऐप्स के लिए एमवीपी मेरा सामान्य दिशानिर्देश है। यदि आप या तो एक करते हैं, तो मैं एएसपी नेट एमवीसी या कैसल के मोनोरेल जैसे ढांचे का उपयोग करता हूं क्योंकि आपके लिए नलसाजी करना दर्द हो सकता है। वहाँ MVC here का एक अच्छा संदर्भ कार्यान्वयन करेंनॉर्थविंडडेटाबेस पर आधारित है कि SQL सर्वर के साथ आया था 2000.

http://nsk.codeplex.com/SourceControl/list/changesets

संबंधित मुद्दे