MVVM 的实际含义是：UI 不是数据。数据是数据，UI 是 UI。

这意味着您不应该以程序逻辑（通常称为业务逻辑）紧密耦合或依赖于 UI 组件状态的方式开发应用程序，而是使其依赖于数据项的状态（无论是 Model 还是 View Model）。

例如，在其他框架（如 winforms）中，如果您有一个包含文本框和按钮的屏幕，则通常向按钮添加一个单击事件处理程序，然后从文本框中读取文本。在 MVVM 中，TextBox 的 Text 属性应绑定到 ViewModel 中的字符串属性，并且按钮也应绑定到 ViewModel 中的 Command。

这允许 UI（即 ViewModel）的抽象，因此，正如我之前所说，您的应用程序逻辑可以不依赖于 UI，而是它的抽象。

这允许 UI 和逻辑中的大量可伸缩性，并且还允许 UI 行为的几个方面的可测试性，因为 UI 行为的很大一部分是在 ViewModel 中定义的。

还有 MVVM 的其他方面，但主要的实现是。

我将添加一个具体的例子，以确保答案的完整性：

1-非 MVVM WPF：

XAML:

<StackPanel>
   <TextBox x:Name="txtLastName"/>
   <Button Content="Click Me" Click="Button_Click"/>
</StackPanel>

后面的代码：

private void Button_Click(object sender, EventArgs e)
{
    //Assuming this is the code behind the window that contains the above XAML.
    var lastname = this.txtLastName.Text; 
    //Here you do some actions with the data obtained from the textbox
}

2-MVVM WPF：

XAML:

<StackPanel>
   <StackPanel.DataContext>
       <my:MyViewModel/>
   </StackPanel.DataContext>
   <TextBox Text="{Binding LastName}"/>
   <Button Content="Click Me" Command="{Binding MyCommand}"/>
</StackPanel>

视图模型:

public class MyViewModel
{
    public string LastName { get; set; }
    public Command MyCommand { get; set; }
    public MyViewModel()
    {
        // The command receives an action on the constructor,
        // which is the action to execute when the command is invoked.
        MyCommand = new Command(ExecuteMyCommand); 
    }
    private void ExecuteMyCommand()
    {
        //Only for ilration purposes, not really needed.
        var lastname = this.LastName; 
        //Here you do some actions with the data obtained from the textbox
    }
}

正如您在上面的示例中看到的，ViewModel 根本不包含对 View 的引用。因此，View 可以是任何东西，只要{Bindings}保持在原位。

神奇地使它们一起工作的胶水是 WPF UI 元素的DataContext属性，它是将解析所有绑定的对象。

还有其他的东西，如属性更改通知中的视图模型，使双向绑定，但这是超出了这个答案的范围。

另外请记住，MVVM 是一种设计模式，而 WPF 是一个框架。MVVM 目前也正在其他技术中应用（目前有很多关于 MVVM 的网络，JavaScript 和类似的东西）

我建议您阅读其他答案中提到的书籍以及this Tutorial以了解更多 WPF 特定方面。

我的问题是，我看到很多评论，用 WPF 编写的应用程序应该使用 MVVM，这将使代码更加可用和可读，我可以将我的代码转换为 MVVM 吗？

没有要求你需要使用 MVVM 模式-没有。你需要考虑你正在构建的应用程序的复杂性和开发组的技能集。一般来说，如果它是一个小型或小型 / 中型应用程序，那么 MVVM可能是过度设计的。如果小组的技能 / 才能不适合单独的演示模式，那么 MVVM 可能不是一个好的决定。

如果做对了，那么 MVVM 会给你带来你读过的各种好处。相反，如果它做错了，那么它可能是一个开发和维护的噩梦 — — 绝对不是更可读和可用的。从个人经验来看，我认为在一个写得不好的代码背后的应用程序上工作比在一个写得不好的基于 MVVM 的应用程序上工作更容易。

当然，您可以将当前的应用程序重写为 MVVM 模式。只需删除您的代码隐藏并将其放入您的视图模型，帮助程序类，存储库类，biz 逻辑类等。

我也使用 SQL 查询，我读了一篇关于 EF（实体框架）的论文，MVVM 和 EF 可以在同一个项目中一起离开吗？

当然可以。只要记住 EF 是一种数据访问技术,MVVM 是一种设计模式。你可能会在你提到的 DAL 类中使用 EF。

最后一个想法是，如果你决定走 MVVM 路线，那么你应该考虑使用一个促进它的框架，比如Prism。

我肯定会考虑DependencyInjection，使用像Unity这样的框架。

您的 Singleton 类可以注册一个 DependencyInjection 容器，并注入到其他类（如 ViewModels）的构造函数中。

DependencyInjection 是开发大型企业软件应用程序时最重要的设计模式，适用于客户端和服务器代码。MVVM 是一个很好的模式，但不会解决与依赖耦合相关的整体应用程序复杂性问题。

这些是我的特定于 MVVM 的

1）增加了视图的“Blendability”（使用 Expression Blend 来设计视图的能力）。这使得有足够幸运的设计师和程序员的团队的责任分离......每个人都可以独立于另一个工作。

2）“Lookless”视图逻辑。视图与在它们后面运行的代码是不可知的，从而使相同的视图逻辑可以在多个视图中重用，或者使视图易于重组或替换。分离“行为”和“样式”之间的关注点。

3）没有重复的代码来更新视图。在代码隐藏中，您会看到到处都是对“myLabel.Text = newValue”的大量调用。使用 MVVM，您可以确保仅通过设置底层属性及其所有视图副作用即可适当地更新视图。

4）可测试性。由于您的逻辑与您的视图完全无关（没有“myLabel.Text”引用），因此单元测试很容易。您可以在不涉及其视图的情况下测试 ViewModel 的行为。这也启用了视图行为的测试驱动开发，这在使用代码隐藏时几乎是不可能的。

其他两种模式在它们解决的问题方面确实是分开的。您可以将 MVVM 与 MVP 和 MVC 一起使用（大多数好的示例都有某种形式）。

事实上，在我看来，MVP（w / a 被动视图，而不是监督控制器）实际上只是 MVVM 的一个变体。