我已经知道MVP和MVC之间的区别。然后在查看应用程序的SRS后,我会陷入困境,需要选择、应用和遵循哪一个作为应用程序架构。
根据我的理解,当存在使用相同业务逻辑的两个以上GUI时(例如公共(www)和管理(winform)部分的应用程序),我会选择MVP。
如果没有这样的情况... 就选择MVC。因为我可以更准确地遵循工厂模式。
伙计们,我不知道,但我觉得如果我必须在它们之间进行选择,那么我就像盲目射击一样。我需要知道。你们对这些有什么看法?
注意:我遵循.net和C#。
我已经知道MVP和MVC之间的区别。然后在查看应用程序的SRS后,我会陷入困境,需要选择、应用和遵循哪一个作为应用程序架构。
根据我的理解,当存在使用相同业务逻辑的两个以上GUI时(例如公共(www)和管理(winform)部分的应用程序),我会选择MVP。
如果没有这样的情况... 就选择MVC。因为我可以更准确地遵循工厂模式。
伙计们,我不知道,但我觉得如果我必须在它们之间进行选择,那么我就像盲目射击一样。我需要知道。你们对这些有什么看法?
注意:我遵循.net和C#。
我认为各种模型视图控制(MVP, Passive View, Supervising Controller, 视图模型, 等等)的区别非常微妙。实际上,所有的问题都是关于谁处理数据以及从谁处获取数据。他们都试图解决同样的问题,即将某物与另一物分离,并且这些解决方案以相似的方式完成所有这些工作。
当您在视觉层面考虑时,这些概念的实现相似几乎是显而易见的:
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时,您负责它应该看起来像什么。
这并不是很重要,因为它们都基于将代码分离成自我服务逻辑实体并减少代码重复的原则。只要保持代码耦合低,最终就应该能够很好地工作。它只有在您想要坚定地遵循应用程序架构时才有意义。
在实际操作中要务实,做最适合您需求的事情,因为最终会得到混合结果。根据SOLID原则进行操作,您应该能够做得很好(请参见关于SOLID的内容)。
我建议您查看是否有MVC或MVP框架以了解如何完成此操作。
我认为你在这方面走在了正确的道路上。对于有多个GUI的应用程序,我通常使用MVP,而对于Web应用程序,则使用MVC。如果你选择其中任何一种,我建议使用框架,例如ASP .Net MVC或Castle's MonoRail,因为自己编写底层代码可能会很麻烦。基于SQL Server 2000附带的Northwind数据库,有一个很好的MVC参考实现here。