我实际上正在尝试提高我的编程技能，因此我决定开发一个简单的桌面应用程序，该应用程序将涵盖其大部分概念。目的是学习编写最简洁的代码。我对 MVVM 架构有几个问题。
首先，我想知道 Model 和 ViewModel 应该做什么，不做什么。我知道这是 ViewModel 的角色，使视图可以观察数据。但是，例如，它可以从文件中获取这些数据吗？或者我应该将此任务委托给模型并让它将数据提供给虚拟机？什么被认为是最佳实践？
我看到有人说，Code-Behind 中完全没有代码是最好的。但是可以改变虚拟机中某些控件的颜色吗？如果没有的话应该去哪里办理呢？
最后一个问题更具体。我想在用户单击按钮时打开一个窗口，以避免将其放入代码隐藏中，我希望此按钮执行在 ViewModel 中声明的命令，但我知道这在 ViewModel 中实例化与 View 相关的对象是不好的.
我发现一个线程说创建一个类，我们称之为 WindowService，它将完成这项工作。然后将其实例传递给 VM 的构造函数。这样做可以吗？为什么这个解决方案没有违反 MVVM 原则？
“视图模型”是一种将“视图”与“模型”隔离的接口/传输机制；就像 ORM 将模型与物理实现（“数据库”）隔离开来。
View是一个物理实现；该模型是一个逻辑实现； ViewModel 弥补了这一差距。如果 View 被替换为全新的技术，ViewModel 能够被“保存”的机会（因为它是使用“MVVM”开发的）充其量是不确定的。
无论你多么努力，你通常都会发现给定的 ViewModel 只能与给定的 View（“上下文”）一起使用；尽管它可以通过“接口”与不同的模型一起使用。花费数小时以某种方式隔离两者（View 和 ViewModel）是值得怀疑的。
因此，没有理由因为这种一对一的 ViewModel - View 对应关系而对“代码隐藏”（IMO）感到不安。此“模式”适用于 WPF、UWP、WinUI2、WinUI3 和 Windows 窗体（文本）“绑定”。而且对于每个相关人员来说都更容易掌握。至于 DTO，ViewModel 能够（或者应该）能够消化它们；更新他们的“代码隐藏属性”；并通知视图。在其他情况下，ViewModel 接受 DTO（或实体）并将其填充到适当的 DataContext 中；取决于正在实施“属性变更通知”的内容。