还有一个MVVM问题…我的理解正确吗?

模型不必是纯数据。模型是应用程序中完全特定于域的部分,没有“表示相关”信息。

此外,尽管“每个模型一个ViewModel”是最常见的工作形式,但有时您可以通过多个ViewModel公开“Model”类。例如,如果您试图仅向设计器公开模型的一部分,这将非常有用,因为它允许您创建较小的ViewModel类。ViewModel调整模型以使用视图—如果不需要整个模型,则可以通过只使用所需的部分使该适配器变得更小(并且更易于测试、维护等)。

就我个人而言,我更喜欢用“每个视图一个ViewModel”来思考,因为ViewModel可以调整一个或多个模型,以便与给定的视图适当地工作,但即使如此,有时为了更改内容而交换同一视图中的ViewModel也是有帮助的。

1. 模型上可以有方法。它们不仅仅是数据。它们可能有“检索”、“存储”等方法。业务逻辑代码。不可知论的观点。

基本上,是的。实际上,不是真的。最佳实践总是在1:1的基础上减少依赖性并在类之间划分职责,但是您会发现在IRL情况下,成为MVC纯粹主义者并不容易。

我要添加的一项不是以MVVM的名义,而是我熟悉的所有MVVM实现所共有的。这是一个消息传递或通知系统,似乎总是作为ViewModel的一个平台进行链接。消息传递只是在可能影响其他人的情况发生变化时通知视图模型。一个好的实现允许视图模型和视图都不知道它们没有通过使用通用通知消息直接绑定到的东西。

很接近。只是说模型只是纯数据是不正确的。它可以而且应该包含针对它执行各种用例的方法。

你的理解是错误的。 可以有多个模型,所有模型都可以有自己的视图,然后成为单个ViewModel的一部分。 例子: 你有模型:产品,顾客 每个控件都有自己的视图,表示为自定义控件 你有一个ViewModel,它把你所有的模型组合在一起,最后在你的应用程序窗口上,你把所有的视图组合在一起,这些视图通过ViewModel与你的模型对话

像这样想。模型就是你的系统,系统所做的一切的精华。它唯一要考虑的是如何完成它的工作,而不是如何使用它。它公开了在系统级别定义的事件、属性和方法,但是它不知道要按什么按钮(或者它是否有按钮!)。它不尝试将数据格式化为更用户友好的格式,而是以模型友好的方式格式化数据。

它应该处理验证(这个年龄是一个合理的年龄吗?)检索数据,转换和缓存正在显示的记录。例如,当您查看病历时,viewmodel从模型中获取数据,并在内部缓存,然后将其发布到视图中。如果模型宣布更新数据会发生什么?把缓存的数据扔掉?如果你编辑过呢?这完全取决于您,应该在视图模型中定义此行为。

视图模型是(通过视图)向用户公开哪些功能和数据的“契约”。视图模型不知道它将如何显示或与之交互。命令应该在功能级别命名,比如RefreshList,而不是MouseClickHandler。

最后是观点。这只是视图模型中内容的可见表示。按钮和菜单等绑定到命令上。字段绑定到属性上,并通过绑定的魔力自动更新。

如果你看到自己在做:“text1.text=value”,那你就错了。如果你发现自己写了一个命令处理程序,上面写着“my.ViewModel.SomeCommand”,那你就错了。