I have been using WPF and Xaml for a while and like it quite a bit. However, I probably am still designing things as I did in the WinForm days with too much code and responsibility in the GUI section.
Anways, in the WPF model what is the GUI responsible for exactly?
If a button in the GUI is clicked should it show the popup and handle any updated values?
If there is validation logic should it check and update the missing/invalid fields?
Should it handle any of the event handler logic such as clicks, value changed, and so on?
This list could probably go on and one. However, I guess the fundamental question is should the GUI only display data from a class and handle getting new data into the class? All other things which is virtually everything should be handled elsewhere.
a wpf gui could technically do anything depending on the approach. You should see some of the first wpf apps I worked with, and am still working with. If you want to follow best practices and make the most of your wpf work then you should use a MVVM pattern.
If you follow this pattern then your GUI should only display data and call commands which are located in the appropriate viewmodel. Even actions such as timers refreshing data should live in the viewmodel. Then you’ll have a model class which provides the composition of the data as well as any validation/coercing that needs to occur.
The idea is to be as generic as possible with the view so that you can easily swap out resource dictionaries, tweak the xaml and have a different look/feel without having to retest all your logic again.
In reponse to your fundamental question, IMHO the view should know how to visualize your data and if you need update/edit behavior then it should know how to call commands on the viewmodel to do that for you. Any other setup starts mucking up the lines between the View/Viewmodel/Model and probably works against you.
Hope this helps. This MVVM article really helped me out:
http://www.codeproject.com/KB/WPF/MVVMQuickTutorial.aspx?msg=3655304#xx3655304xx