很抱歉，如果这是重复的，那不是'什么是MVVM'，而是'这是MVVM'，我读了很多，并且认为我对它的基本了解是什么是的，我有自己的'单线'，就这样，我如何解释它，但想要确保它是正确的，然后我坚定地把它放在脑子里，
本质; Model是纯数据 - 没有方法，每个Model有一个ViewModel，它拥有对Model的引用 - 它对Models数据执行所有更改，最后View将保存一个（或多个）ViewModel引用和格式＆安培;显示ViewModel提供的数据。
（不是在链接到教程，博客等之后，只是一个是，或者没有调整就好了，因为如果没有，我将不得不重新阅读所有内容:)）
答案 0 :(得分：7)
不完全 - 至少，不是我完全定义它。
模型不一定是纯数据。该模型是您的应用程序中完全特定于域的部分，并且没有“与演示相关”的信息。
这通常包括所有特定于域的数据，但也可能包括纯业务逻辑和数据访问等方法。任何特定于业务逻辑和流程的内容，而不是“显示”的一部分，都是该模型。
此外，虽然“每个模型一个ViewModel”是最常用的工作形式，但有时您可能会通过多个ViewModel公开“模型”类。这可能很有用，例如，如果您尝试仅将模型的一部分暴露给设计器，因为它允许您创建较小的ViewModel类。 ViewModel使模型适用于View - 如果不需要整个Model，只需使用所需的部分就可以使这个适配器更小（更容易测试，维护等）。
就我个人而言，我更喜欢用“每个View一个ViewModel”来思考，因为ViewModel可以调整一个或多个模型以便与给定的View一起正常工作，但即使这样，有时候换出一个ViewModel会很有帮助在同一个视图中，以便更改内容。
答案 1 :(得分：4)
关闭，但不完全。以下是与您不同的一些观点：
模型可以有方法。它们不仅仅是数据。他们可能有“检索”，“存储”等方法。业务逻辑代码。查看不可知论。
对于有多少ViewModels持有对模型的引用没有限制。 ViewModels封装了视图级行为，因此您可能对同一模型有许多不同的行为集。例如，一个ViewModel可能是模型项的只读转换。另一个可能会在同一个模型项上提供读/写表单验证。
根据您想要的行为，每个视图可以有多个ViewModel。例如，您可能包含一个ViewModel的“高级内容”行为和另一个ViewModel的“免费内容”行为，但保持相同的视图。
答案 2 :(得分：1)
基本上，是的。实际上，不是真的。最佳实践总是减少依赖关系，并以1：1的方式在课堂之间分配你的职责，但是你会发现IRL情况下，成为MVC纯粹主义者并不容易。
我认为最好的态度是尽力而为，然后记录其余部分。不要过分冒汗。
答案 3 :(得分：1)
这里有很多很棒的信息，我认为大多数答案都是正确的。我认为没有任何具体的定义，在这个问题上也没有1个具体的权限。甚至微软也没有明确的定义。
我要添加的一个项目不是MVVM的名称，但是我熟悉的MVVM的所有实现都是通用的。这是一个消息或通知系统，它似乎总是作为ViewModel的平台链接。当事情发生变化时，Messaging只会通知View Models，这可能会影响其他人。考虑到这一点的良好实现允许View Models和Views通过使用通用通知消息对它们不直接绑定的内容不可知。
在我看来，整个模式的好处是使应用程序具有模块化，可交换的部分，尽可能减少类型依赖。
在我看来，这是一个真正缺失的部分，因为它提供了从MVC模式中的单独控制器逻辑中获得的相同优点/功能。
答案 4 :(得分：0)
这非常接近。除了说模型只是纯数据是不正确的。它可以而且应该包含针对它执行各种用例的方法。
答案 5 :(得分：0)
你的理解是错误的。 您可以拥有多个模型，并且所有模型都可以拥有自己的视图，然后成为单个ViewModel的一部分。 例： 您有模型：产品，客户 他们每个人都有自己的视图表示为自定义控件 您有一个ViewModel，它结合了您的所有模型，最后在您的应用程序窗口中，您将所有视图组合在一起，通过ViewModel与您的模型对话
答案 6 :(得分：0)
这样想。模型是你的系统，系统的功能和内容。它唯一的考虑因素是如何完成它的工作，而不是如何使用它。它公开了系统级别定义的事件，属性和方法，但它没有按下按钮的概念（或者甚至是按钮！）。它不会尝试将数据格式化为更加用户友好的格式，而是以模型友好的方式格式化数据。
视图模型是UX（用户体验）。它定义了您将如何使用该系统。它定义（通过公共命令和属性）用户导向的系统访问。它是用户进入系统的桥梁。它绑定到模型的事件，通过它的命令，它将提供对模型功能的访问。
它应该处理验证，（这个年龄是一个明智的年龄吗？）在显示记录时检索数据，转换和缓存记录。因此，例如，您正在查看患者记录，viewmodel从模型中获取数据，并在内部对其进行缓存，然后将其发布到视图中。如果模型宣布对该数据进行更新，会发生什么？扔掉缓存的数据？如果你编辑了怎么办？这完全取决于您，并且应该在视图模型中定义此行为。
视图模型是向用户公开哪些功能和数据（通过视图）的“契约”。视图模型没有如何显示或与之交互的概念。命令应在功能级别命名，例如RefreshList，NOT MouseClickHandler。
最后，查看。这只是视图模型中可见内容的可见表示。按钮和菜单等绑定到命令。字段绑定到属性，并将通过绑定的魔力自动更新。
如果你看到自己在做：“text1.text = value”你做错了。如果你发现自己编写了一个命令处理程序，说“my.ViewModel.SomeCommand”你做错了。