* MVVM中添加VM的主要目的*
我们可以说：
ViewModel 是在 MVVM 中引入的，用于对代码进行单元测试。
如果我们比较MVC 和 MVVM，那么在没有 View 的情况下， MVC对 Controller 进行单元测试是很困难的。
因此我们又添加了一层ViewModel来对主要代码进行单元测试。
管理 Model 不持久化的一些非持久化数据。ViewModel 被引入来管理一些非持久化数据，并根据用户输入将数据通过Model持久化到数据库中。
验证模型中的数据更改并按照命令保留。
管理数据绑定。
而且我还看到大多数命令绑定的 MVVM 示例都包含ViewModel在执行某些命令时初始化另一个视图。这直接表明视图依赖于 ViewModel。
视图 --> 视图模型 --> 模型
ViewModel应该是一个独立的可测试单元。
从 view#1 初始化 view#2 的代码应该是 view#1 代码隐藏文件的一部分。
例子 ：
如果我想调用 MessageBox(view#2)。消息框应该在View#1中调用，并根据消息框结果（是\否）来执行操作，我们应该在ViewModel#1中调用适当的方法。有了这个ViewModel将独立于视图，我们可以轻松编写单元测试。
“ViewModel 是在 MVVM 中引入的，用于对代码进行单元测试。”
不完全是。正确解耦的代码很容易测试。但这是良好设计的好处，而不是原因。代码被解耦并分割成更小的单元，因为更小的单元可以被理解，而由 50'000 行代码组成的单个神对象类无法被完全理解。
我们将代码分解为具有小而有限的接口的独立部分，以便可以孤立地看待问题，并且对一个类的更改不会对整个系统产生连锁反应。副作用是，这些部件变得足够简单，可以通过单元测试进行全面测试。
强制开发人员编写单元测试会更加激励开发人员正确设计类，因为如果类的职责选择不合理，则测试会更难编写。但如果开发人员已经关心这一点，无论单元测试如何，那总是更好。
回到视图模型。模型就是数据。ViewModel 是可呈现格式的数据。对于简单的一次性程序，它们可能是相同的，但通常模型中的数据有一些限制，例如必须可序列化，或者从其他地方提供。ViewModel 更改数据的格式。
您甚至可以为单个模型拥有多个 ViewModel，从而为不同的视图以不同的方式呈现数据。多个相似的 View 可能共享相同的 ViewModel，尽管这种关系通常是 1:1。
您是正确的，ViewModel 一定不知道 View，而 Model 一定不知道 ViewModel。
| 归档时间： |
|
| 查看次数： |
333 次 |
| 最近记录： |