MVP（Model View Presenter）或MVC（Model View Controller）

我已經知道MVP和MVC之間的區別。然後，在通過應用程序的SRS之後，我會得到一個Fix，這個應用程序需要選擇，應用並遵循Applcation Architecture。根據我的理解，我會從超過2個GUI中選擇使用相同業務邏輯的機會。就像一個公共（www）和Adming（winform）部分的應用程序一樣。如果沒有這樣的...尋找MVC。因爲我可以更準確地跟蹤工廠模式。MVP（Model View Presenter）或MVC（Model View Controller）

花花公子，我不知道，但我覺得我只是玩盲注，如果我要選擇其中。我需要知道。你們對這些有什麼看法？

注意：我關注.net和C＃。

來源

2010-01-16 Sumeet

在我心中的模型視圖控制器模式的所有變化的差異（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 +------+

他們是在類層次結構可能看起來是一樣的兩個相近。不同的是顯示和操作數據的方式不同。當你推出你自己的MVC時，你負責它應該是什麼樣子。

這並不重要，因爲它們都基於將代碼段分成自服務邏輯實體和減少代碼重複的原則。只要你保持code coupling low它最終應該很好地工作。只有當你想在應用程序的體系結構中以教條形式出現時才重要。

務實一點，做到最適合您的需求是最好的，因爲無論如何您最終都會混合在一起。根據視圖的需要，在各種變體之間切換應該「相當」容易。按照SOLID的原則，你應該沒問題。（另見this about SOLID）。

我建議你看看是否有MVC或MVP框架來看看它是如何完成的。

來源

2010-01-16 09:13:19 Spoike

+ 1..always升值ASCII圖在回答一個很好的參考實現。 – 2010-01-16 13:57:34

spoike：你的回答很有說服力。謝謝。 – Sumeet 2010-01-19 04:28:22

我認爲你在這裏的正確軌道上。對於具有多個GUI和適用於Web應用程序的MVC的應用程序，MVP是我的一般準則。如果你這樣做，我會使用ASP.Net MVC或Castle的MonoRail這樣的框架，因爲你自己做管道可能會很痛苦。有MVC here的基於Northwind數據庫與SQL Server 2000來

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

來源

2010-01-16 20:36:39 LWoodyiii

MVP（Model View Presenter）或MVC（Model View Controller）

回答

相關問題