关于MVP和MVVM的几点混淆

Question

关于MVP和MVVM的几点混淆

在问这个问题之前，我读了一篇关于MVP和MVVM的文章。（例如：http://martinfowler.com/eaadev/uiarchs.html）

null

例如，富客户端应用程序将同时使用本地数据库和远程服务。

在业务层，有两种对象！

域对象，它是从我的本地数据库中读取的。

在MVP中，只有一个“模型层”，所以我可以在这个模型层中管理和存储domian对象和session对象。所有视图特殊状态都在视图中，不会持久化。演示者将控制视图状态，并在模型和视图之间同步数据。

在MVVM中，有两个“模型层”（模型和ViewModel)，视图状态和模型的副本存储在ViewModel中。那么复制的模型是多余的吗？

还是仅仅将外部服务调用放在分离的模型层中？

Answer 1

>

MVC最初将模型定义为“存在于计算机中的数字模型”，而不是“人类用户的心智模型”。因此，它是一个非常模糊的概念，可以涵盖您想要的任何实际情况，尽管后来出现的无数MV*实现引入了更多的固执己见的定义。

思想流派中的一个传统冲突是，MVC/P中的模型应该是一个领域对象，还是仅仅是呈现给用户的内容的反映。MVVM给出了一个明确的答案（参见2.和3.）

不，因为ViewModel只是一个暂时的内存结构，代表屏幕上显示的内容。如果说MV*模式中有什么要坚持的，那就是模型。

例如，UserCredentials模型对象将包含登录和密码字段，而相应的UserCredentialsViewModel可能包含一个额外的ConfirmPassword字段和一个VerifyPasswordMatchesConfirm()方法，因为这就是显示给用户的。

另一个主要区别是MVVM中存在基于事件的数据绑定，这在MVP中是不存在的。一个结果是，您经常会看到在客户端使用MVVM模式，其中有允许这种绑定的技术(Javascript、WPF)，而MVP主要是在服务器端使用（主要是ASP.NET）。MVP并不比MVVM好，它们只是适合不同的生态系统。

Presenter和ViewModel正如它们的名字所暗示的，是UI猛兽。如果您将DTO传递给他们，他们可能能够看到远程服务调用产生的DTO，但他们不应该调用远程服务，因为这样做不是表示对象的责任。您应该在一个单独的基础结构服务中这样做。