Question

我已经知道MVP和MVC之间的区别。然后，在完成应用程序的SRS后，我会进入一个需要选择，应用和遵循Applcation Architecture的Fix。根据我的理解，我会从两个以上的GUI中选择可以使用相同业务逻辑的MVP。喜欢使用公共（www）和Adming（winform）部分的应用程序。如果没有这样......寻找MVC。因为我可以更准确地遵循工厂模式。

伙计，我不知道，但如果我愿意在他们中间做出选择，我觉得我只是盲目投篮。我需要知道。你们对这些有什么看法？

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

Answer 1

在我看来，模型视图控制器模式（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框架来了解它是如何完成的。

Answer 2

我认为你在这里走在正确的轨道上。具有多个GUI和用于Web应用程序的MVC的应用程序的MVP是我的一般准则。如果你做任何一个，我会使用ASP .Net MVC或Castle的MonoRail这样的框架，因为自己做管道可能会很痛苦。基于SQL Server 2000附带的Northwind数据库，MVC here有一个很好的参考实现。

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

MVP（模型视图演示器）或MVC（模型视图控制器）

2 个答案: