Wpf 将视图绑定到模型的属性而不是ViewModel有什么不好？

我经常听说模型必须由ViewModel包装，即视图未与模型耦合/未意识到它

在MVC中，将视图绑定到模型是很常见的。。。没人抱怨那又怎样

---

我害怕创建所有的包装，几乎只做复制属性的工作。

在某些情况下，您不需要这样做，就像在许多情况下您不需要属性，但可以避开公共字段一样

---

但是您的模型应该镜像域结构和逻辑，而视图模型则镜像UI结构和逻辑。至少，据我所知。这两种模式不一定相同，并且每种模式都可以独立于另一种模式进行更改。

您应该始终对您的个别问题应用一种模式，并在不适用的区域对其进行修改。仅仅因为模式意味着视图模型的使用，并不意味着在每个场景中都需要一个视图模型。如果您的模型公开了所有需要的属性，并且不需要进一步的抽象，那么可能不需要视图模型

---

但是，在许多情况下，视图模型最终将非常有用，并且比向模型添加额外属性更容易维护。在直接绑定到模型之前仔细考虑这个问题。

< P> ViewModel只用于传递您真正需要的数据到视图。 使用模型而不是viewmodel时，可能会使用直接来自数据库的数据

当以错误的方式使用模型时，可能会编辑数据库中不希望编辑的数据

---

使用ViewModel更安全。

一个似乎没有（直接）出现的点然而，ViewModel可以轻松地支持甚至不应该出现在模型中的数据，例如搜索文本框中键入的文本或选定的列表项，以防命令或进一步的数据绑定中需要这些值，并且每次将它们作为参数传递似乎太麻烦了

---

但如前所述，如果您确信所需的所有数据都已在模型中可用，请继续使用ViewModel。

ViewModels非常方便的一种常见情况是，应显示枚举值。在我看来，ViewModel是将枚举值转换为用户友好表示的完美场所。您甚至可以在ViewModel中引入本地化步骤

此外，ViewModels还可以简化其他一些场景。但是，正如您所说，它们也可以复制大量代码。也就是说，您可以创建一个带有Model属性的ViewModel，该属性允许直接绑定到Model类的属性。现在，如果您以后意识到需要一些转换步骤，仍然可以将该属性添加到ViewModel并绑定到该属性

---

但我认为在大多数情况下，从一开始就使用ViewModel是有意义的，因为在以后的开发阶段可能很难引入它。

这取决于可能的指标：例如，如果您的模型是由EF提供的，那么向您的视图公开它是没有意义的-为什么视图需要所有模型的方法/属性和大量的数据东西（不提数据安全性），但如果您的模型非常简单，并且您觉得，您不会通过和VM对其进行太多的扩展/更改，那么使用它的过程中没有什么事情是这样的：）

在可能的情况下，从您的视图直接绑定到模型是没有问题的

但是，您会发现，您很快就会遇到这样一种情况：您需要对视图所需的内容进行建模，而这些内容不在您的模型中

考虑到你永远不想用视图问题破坏你的模型，你别无选择，只能创建一个视图模型

你可能会问，“把我的程序的所有功能放在一个大类中有什么错？”一方面，没有错；可以让它工作。另一方面，一切都是错误的：如果你的程序是一个大的线球，你必须把所有的线都弄直才能改变它

看看一个由初学者编写的Windows窗体程序员。您将在按钮的Click事件处理程序中找到所有业务逻辑。怎么了？您不希望在用户单击按钮时执行该逻辑吗

---

这基本上就是你在WPF世界中所提议的。行吗？当然对于琐碎的项目，它甚至可以很好地工作。不过，您正在积累技术债务，到时候，您必须通过将代码重构为可管理的内容来偿还债务。

我没有问过为什么要在软件体系结构的类中分离代码。我的问题是关于绑定到models属性而不是viewmodel。。。完全不同的主题。它完全是同一个主题。这为我提供了解决方案：“但是您的模型应该镜像域结构和逻辑，而视图模型镜像UI结构和逻辑”我已经写了一篇关于是创建视图模型还是直接绑定到模型的帖子：。我总是创建一个视图模型类，并建议这样做，尽管我的论点可能看起来有些牵强，但我的选择从未让我失望。