So you are thinking of doing VVM, instead?
(e.g. View-ViewModel)
I think if you search for "NoUserHere" in this forum he has a long post here regarding how even one of the designers of WPF and MVVM were backing off from the religious clinging to always using MVVM when using WPF.
In general, WPF was designed to work very well with a MVVM. It was designed by folks in the Microsoft's Avalon project along the lines of what they thought of as the ideal desktop workflow where architects and developers (and program managers) could focus on the working on the Model, while the UI designers (and program managers) could focus on working on the View independently. Additionally, localizers can then take the View and modify as needed for all the various cultures. The View Model would act as an adapter layer to allow the developers map the Model into the View. The M, V, and VM could be compiled independently of each other and just be married together at link time and everything should just work.
But there's nothing preventing you from also using WPF following the traditional WinForms/Win32 API style where you just mix-in the model (e.g. all the data going stored in the controls themselves and/or as class or global variables closely associated with the view) and controller code (e.g. all the event handlers) in along with the view.
There's also nothing preventing you from using one of the other MV* patterns. If you tend to think along MVC (Model-View-Controller) better, then use MVC. If you prefer MVP (Model-View-Presenter), then use MVP. Personally, I tend to write WPF more along the lines of MVVMC (Model-View-View Model-Controller) when I start noticing that I have a lot of business logic that needs to be testable independent of the View Model.
My advice is to write code that is maintainable. If you want to lump everything into the code behind have at it. Good luck with unit testing, though.
