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）

回答

相关问题