What is WPF for the WinForms programmer?

Question

What is WPF to the WinForms programmer?

WinForms distilled is adding controls to forms, and adding event handlers. This is simple and easy and allows you to make functio

Answer 1

WPF brings

• Declarative UI Programming: The presentation or look of the UI (XAML) has been separated from the code (.cs et. all) such that the XAML can be created independently by people who are good at that sort of thing - graphic designers. They then submit their finished look to the developers who just write the code to make it work. (Simpler stuff can be handled again directly in XAML) Supposed to give you greater parallelism and good UX (as opposed to developer-approved-UIs)
• Data Binding: Again a declarative bent.. You declarative specify which model property this UI control renders, WPF takes care of pulling the data into the control & updating modified contents back along with change notifications.
• Improved Composite Control Model - You can now embed almost anything within anything so now imagination knows no bounds.
• Data Templates, Control Templates etc.. - again separation of UI from code. These XAML templates specify (once) how a data structure or UI Control should look to the user.
• Better at X: Ofcourse MS improved on a bunch of other aspects like rendering (fewer updates that GDI), Scaling (resolution independence), Transparency, Layouts (Non-absolute), Text rendering, Animation & Video support, An Improved Event Model, et. all
• Styles, Triggers : Easier to apply uniform look-n-feel globally with in-one-place styles (XAML again). Triggers are blocks of code that execute when some event occurs e.g. 'the text of this control changed.. so now update its foreground property to blue to indicate "modified"'. Simple stuff can be done directly in XAML.

Answer 2

Visual Studio 2008 contains a WPF Designer.

This video might be of interest: Create a C# WPF Application in Visual Studio 2008

Answer 3

I found XAML to be a bit complicated, too, at the beginning, but once i got used to it, i found it to be pretty simple (once you know the basic controls). One of the best things about it is Databinding.

Usually when i write a WPF application, i use it for pretty much everything on my UI. Binding controls to Commands and properties of a viewmodel can completely separate presentation from design, i usually have not a single line of code in my code-behind. That makes my ViewModel/business logic objects easily testable and completely independent from any visual representation, which in turn can be easily replaced.

Answer 4

I've been working almost exclusively in WinForms for the past 4 years and have begun using WPF for a couple of small projects at work. The learning curve is steep. But once you get used to it, it's well worth it.

WPF is much more than just visual eye candy like skinning or animation. Even for basic applications to track shipping orders, you can leverage WPF. WinForms only takes you so far with its controls. If you wanted to display slightly customized UI, you often needed to do custom draw in your controls using GDI, which can quickly become a nightmare. In WPF, customizing anything is trivial through data templates. You can easily customize list box elements, add controls to list view columns, or headers, etc. WPF allows you to take control of complex UI layouts with its powerful layout system. I'm also amazed at how little code is needed in WPF to accomplish the same things I used to do in WinForms, so this means less bugs and easier to maintain applications.

Answer 5

I suppose one way of looking at it would be to consider HTML + CSS webpages. We had HTML and that was great, except things were all jumbled together. What people realized is that with CSS, you could separate the structure of the document from its presentation. XAML does the same thing, or at least allows and encourages it.

As for practical benefits, skim through the MSDN examples. I tend to think WPF is more geared towards so called "rich media", with much more complex elements. Your example of an app that tracks shipping orders isn't a good one, particularly since a number of those systems still run in DOS based interfaces.

Answer 6

Here I am trying to answer in a very simple naive terms about some of the WPF questions which the beginners/winforms developers face and something which I faced when I started off with WPF. There are many articles and tutorials in the internet which gives enough knowledge, but it’s difficult to find answers to very simple questions. I am trying to address it here.

What is WPF?

Windows Presentation Foundation as the expansion goes; it is a “Presentation” system for building windows applications. If you are a winforms developer the major difference you would find in WPF is that the way designer looks. Unlike in winforms the designer code is not the C# code but the XAML code.

Why WPF?

Well, the major reason for WPF being preferred over the winforms is that WPF provides rich UI. Apart from this there are many other benefits that WPF provides, it is available more clearly in many tutorials in the internet. It is a vector based rendering engine. If one just compares the UI of a winform application and a WPF application the difference in terms of look and feel would be quiet clear.

What is MVVM?

MVVM is a pattern, which is adapted while developing the applications. It is expanded as “Model View View Model”, basically while structuring the project we have a model folder under which all the model files (.cs) would be placed, under the view model folder all the viewmodel files(.cs) would be placed and under the view folder all the view files(.xaml) would be placed. If MVVM is used then there won’t be any code behind that means .xaml.cs file would not have any code except for the auto created method.

Model : Model has the business logic part which supports the view model with the data that would ultimately be presented in the view.

ViewModel : Every view would have a view model. Viewmodel would implement INotifyPropertyChanged Interface, and would have all the properties that are binded to the corresponding view. View model is not loaded with any business logic and the responsibility lies with the model.

View: View is nothing but the xaml file where the window is designed. XAML is a markup language. In WPF unlike in winforms every control would be binded with a dependency property either predefined or user defined.

Why MVVM?

Whenever an application is being developed in WPF, MVVM comes handy with it. One of the biggest advantages of using MVVM is that it makes possible for a UI independent unit testing, since there is no code behind during unit testing no UI related objects are required and hence 100% code coverage is possible. In unit test, ‘commands’(look for commands in wpf) could be passed by the user to test a particular usecase.

Is it a mandate or an absolute necessary to go with MVVM when working with WPF?

I would say no, it is not mandatory to go with MVVM when working with WPF however it depends upon the requirement. One has to look into the advantage MVVM provides and then decide whether to go with it or not. MVVM adds on to the complexity during the initial days of development but ultimately it comes with its benefits. If the complete application is in winforms and only a small module rather a small feature is being developed in WPF then it would not be necessary to follow MVVM, one can happily have code behind and get the rich UI experience. Again I would repeat it completely depends on the type of requirement.

Can I have multiple view models to a single view / multiple views to a single view model?

This is a question for which I have not got a clear crisp answer in any .net communities. First of all as we saw that the main intention of going with MVVM is for achieving 100% code coverage, this makes it obvious that we are going to test every viewmodel independently and hence a complete form is tested. Having this in view it is better to go for one view one viewmodel approach. We can always communicate between the viewmodels if there is a necessity by using MVVM Light messenger or any other means which facilitates it.

What is the difference between viewmodel and model?

This is one question which the beginners would always have since they do not find much difference between the two. Here is the difference:- Model is nothing but a class which has the data-methods to modify the data, which would be used in the viewmodel and ultimately binded to the view. ViewModel just has the properties which would be binded to the view. In the get or set methods one can call a method in model to get the data. Again this model is for this particular view model. Now you can decide if you really need a model class, if there is no heavy business logic then you can avoid a model class and place it in the viewmodel, but the cleaner would be to use a model class.

In MVVM, can I skip a view model or a model class for a view?

Again it depends on the requirement as earlier mentioned , if there is no heavy business logic then you can avoid a model class and place it in the viewmodel, but the cleaner approach would be to use a model class.