WPF Programming Methodology

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.

My question is, I see a lot of comments that an app written in WPF should use MVVM, and this will make the code more usable and readable, can I transform my code to be MVVM?

There's no requirement that you need to use the MVVM pattern - none. You need to consider the complexity of the app you are building and the development groups skill-set. Generally speaking, if it's a small or small/medium app then MVVM may be over-engineering. If the group's skills/talent aren't a good fit for a separated presentation pattern, then MVVM may not be a good decision.

If done right, then MVVM gives you all the sorts of benefits that you've read about. Conversely, if it's done wrong, then it can be a development and maintanence nightmare - definitely not more readable and usable. From personal experience, I think it's easier to work on a poorly written code-behind app rather than a poorly written MVVM based one.

Sure, you can rewrite your current app to the MVVM pattern. Just remove your code-behind and put it into your view-models, helper classes, repository classes, biz-logic classes, etc. Don't fall into the trap of putting everything into you view-models, creating an MVVM-glorified code-behind.

I also use SQL queries and I read a paper about EF (Entity Framework), can MVVM and EF leave together in the same project?

Sure, they can. Just remember that EF is a data access technology and MVVM is a design pattern. You'll probably use EF in your DAL classes that you mention.

One final thought, if you decide to go down the MVVM route then you should consider using a framework that facilitates it, like Prism. Oh, and be prepared for quite a bit of learning and frustration.

I would definitely look into DependencyInjection, using a framework like Unity.

Your Singleton classes could be registered with a DependencyInjection container and injected into constructors of other classes (such as ViewModels). So could other DAL classes which need to be instantiated regularly and injected into classes.

DependencyInjection is the single most important design pattern when developing large enterprise software applications and is applicable for both Client & Server code. MVVM is a nice pattern but won't address the issue of overall application complexity related to dependency coupling.