我在WPF中对MVVM的概念是我们为应用程序中的每个Model都有一个ViewModel。这意味着如果我们有Customer类（实体），那么我们将拥有CustomerViewModel。 CustomerViewModel将具有代表客户所需的所有属性。 CustomerView用户控件将负责为Customer模型创建UI。
现在，让我们说我们正在增加一个新客户。所以，我们有一个由FirstName，LastName等组成的表单。我们需要一个ViewModel来实现这个场景。我的意思是我所要做的就是从TextBox中获取所有输入值并创建一个Customer对象，然后将其保存到数据库中。为什么我要为这种情况创建一个ViewModel呢？
答案 0 :(得分：3)
首先，这不是MVVM的主要目的，是为了“镜像”一切。 View应提供用户输入的方法，当然不会处理对任何数据库层的调用。 ViewModel应该是一个与GUI无关的应用程序主干，它肯定应该处理客户的创建。
那就是说，你应该做的是拥有一个ViewModel，它代表一个处理客户的工作空间，而不仅仅是一个客户ViewModel。如果您确实想要保存正在创建的几个对象，请添加到该工作区，以创建和添加新客户（而不是CustomerViewModel）。这样，您可以拥有工作空间视图，其中包含客户的每个相关/必需属性的元素，并通过调用添加到该工作空间ViewModel的某个命令，您可以获取当前值（填充到ViewModel的数据）直接向客户模型查看元素。
考虑一下，如果你稍微重构一下，你是否可能放弃特定的客户（以及其他模型）ViewModel，那么在没有明确原因的情况下，不要盲目地坚持某种模式是好的做法。
答案 1 :(得分：2)
您不需要为Add添加单独的ViewModel，您只需要一个ViewModel，它应该执行编辑和添加方案。如果您可以从编辑页面删除记录，那么ViewModel也应该能够删除。您的ViewModel应该反映您的View公开的功能，无论数据如何。
我认为您应该重新考虑为每个模型设置一个ViewModel。我喜欢将ViewModels视为插入数据的规范化行为。通过为每个Model类提供ViewModel，您迟早会遇到架构问题。我从上到下概述了应用程序，我的UI试图完成什么，从那里我将进入ViewModel，最终我将进入我的DataFactory以及ViewModel映射到数据的方式几乎总是不是1比1对于最简单的观点。如果您尝试将1映射为1，则会出现错误的UI，或者您的数据无法很好地规范化。
我们在这里的筹码是：
这里需要注意的是ViewModel包含来自多个POCO的属性！
我们通过StructureMap和Unit测试注入DataFactory和xUnit以及Moq。
要回答第二个问题，我会创建一个单独的仅查看视图作为用户控件。但是你应该在你的app中有一个CRUD ViewModel，它以用户友好的方式封装了所有这些功能。
感谢。
答案 2 :(得分：2)
让我们假装没有商业模式。您拥有的唯一是一个视图。如果您只是模拟该视图，而不知道数据在系统中其他地方的含义，那就是ViewModel。
ViewModel的目标是为它支持的视图建模。这与在业务领域中对客户的想法进行建模的目标不同。假设每个业务实体将拥有一个ViewModel，那么，就是说每个业务实体将拥有一个视图，从而导致以普通数据为重点的UI。
在您的特定情况下，请考虑客户编辑视图。它具有与客户属性相对应的字段，因此看起来非常适合直接绑定到客户。但是，客户对象上的“提交”操作是建模的吗？ “取消”动作在哪里建模？在哪里建模，字段X是从列表中选择的枚举值？
密码怎么样？如果持久化为二进制散列值，视图是否知道如何散列其文本？如果系统有密码强度要求怎么办？
ViewModel是业务模型和UI之间的重要组成部分。它需要一个人的关注并将它们转化为另一个的术语。这是解决上述所有问题的关键所在。要说ViewModel不是必要的，就是忽略它的必要性。
答案 3 :(得分：0)
此VM抽象的一个原因是可测试性。您想要ViewModel的另一个原因是它基本上是一个数据传输对象，它可能是来自单个容器中多个模型的字段的组合，这些字段与您当前的视图更相关。拥有VM的另一个原因是利用WPF两种方式绑定功能。
使用常规模型（普通POCO），您可以在模型更改时更新View，但由于模型未实现依赖项属性（最有可能），因此您将无法在更新模型时使用WPF控件中的值更改。这意味着您必须手动添加处理程序并将此值从此控件复制回模型类型。