The actual meaning of MVVM is: UI is not Data. Data is Data, UI is UI.
This means that you should not develop the application in a way that the program logic (often called business logic) is tightly coupled or dependent on the state of UI components, but instead make it dependent on the state of data items (be it the Model, or the View Model).
For example, in other frameworks (such as winforms), if you have a screen that contains a textbox, and a button, you usually add a click event handler to the button and then read the text from the textbox. in MVVM, the Text property of the TextBox should be bound to a string property in the ViewModel, and the button should be bound to a Command in the ViewModel as well.
This allows for an abstraction of the UI (which is the ViewModel), so that, as I said before, your application logic can be dependent on not the UI but an abstraction of it.
This allows for a huge amount of scalability in the UI and the logic, and also allows for the testability of several aspects of UI behavior because a big portion of the UI behavior is defined in the ViewModel.
There are other aspects of MVVM as well, but the main realization is that.
Edit:
I will add a concrete example of this for completeness of the answer:
1 - Non MVVM WPF:
XAML:
<StackPanel>
<TextBox x:Name="txtLastName"/>
<Button Content="Click Me" Click="Button_Click"/>
</StackPanel>
Code behind:
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>
ViewModel:
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 illustration purposes, not really needed.
var lastname = this.LastName;
//Here you do some actions with the data obtained from the textbox
}
}
As you can see in the above example, the ViewModel contains no reference at all to the View. Thus, the View could be anything, as long as the {Bindings} are kept in place.
The glue that magically makes them work together is the DataContext Property of WPF UI Elements, which is the object that all bindings will be resolved against.
There are other things, such as the Property Change Notification in the ViewModel to enable two-way bindings, but that is out of the scope of this answer.
Also keep in mind that MVVM is a design pattern, whereas WPF is a framework. MVVM is also being currently applied in other technologies (there is currently a lot of buzz about MVVM for the web, with JavaScript and stuff like that)
I suggest you read the books mentioned in other answers as well as this Tutorial for more WPF-specific aspects.
