What is a WPF GUI responsible for?

Question

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.

Answer 1

Your GUI code (aka your view) should simply provide a way to display data and invoke functionality in your model (or view model if you need one).

If you're doing it right, most of the time your view will be pure XAML with no code-behind at all. Sometimes you will need a little code if for example you have a few buttons that interact in a strange way. In these cases I often encapsulate that functionality into a custom control.

Also, if you're doing it right you usually will have almost code in your view models and many views won't need view models at all.

To answer your specific questions:

• If a button click in the view should show a popup that appears every place the object is visible (ie the object changes to a new state), the button sets a property of the view model and the template shows the popup whenever the property is true.

• If a button click in the view should show a popup only in the view where the button was clicked, the popup should be defined using an event trigger so it appears when the button is clicked.

• If a button click in the view should toggle a boolean value, just a ToggleButton or one of its subclasses and bind it to the value.

• If a button click in the view should assign a single value to a single field, it should have a command attached that does exactly this (ie. you might have a "SetProperty" command with parameters that indicate which property and what value).

• If a button click in the view should update multiple values or do so in a complex way, you should use a view model and handle the complexity there.

• If a button click should do two separate things (such as update values and show a popup), you should implement a multicommand class to allow you to express the dual action in XAML.

• If there is validation logic to check for missing required fields, it should be in your model itself because the concept of valid is inherent to that object. A property of the model object should indicate if there are missing fields.

• If there is validation logic to check for requirements specific to the particular view, it should be in your view model. Again, a property of the view model is bound by the view to display validity and disable UI (such as a submit button).

• Your view should never handle a Click event except in a trivial one-minute program. You should use a command, either a built-in one or one you define. For simple cases a command can be called using only XAML (eg SetProperty or Paste). If custom code is required to handle your command, that code should be in your model or view model.

• Your view should never handle value changed events. WPF's binding system is very good at handling these. In situations where WPF's built-in mechanism isn't enough, a custom control or attached property should be created that handles the specific scenario.

Answer 2

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

Answer 3

You can implement it many ways. WPF does not really care.

But there are many architectural patterns for handling GUI. Most of them puts as little code in the GUI parts as possible. Most patterns, like MCV/MVP, fits many GUI toolkits. A pattern that is designed specifically for WPF is MVVM. To learn MVVM you can by a book, google for it or watch some videos depending on how you like to learn things.