Simple yes, but how/why does it work?

May 5, 2010 at 9:44 PM
Edited May 5, 2010 at 10:13 PM

Thank you for publishing a simple XAML binding example.

How/why does this work?

What comes first?

In what order does the code execute?

Why is there a UserControl involved?  I found that the App.xaml.cs file references it:  this.RootVisual = new SimpleView();  But why?  Why not use a Window, why a UserControl?  Am I to just copy and paste this code or understand it?  Where do I turn to learn how this works?

Can you draw a UML model of the objects and their interactions?

I have six code files open in Visual Studio and I am not sure, really sure, which does what and when.

XAML is not a programming language.  It has no verbs, no statements, no process flow.  What is it then?  I must understand the engine that harnesses the XAML if I am to understand what the XAML is for and why it is written as it is.  I can see that XAML has many aspects that are better than WinForms.  But I also see a big drop in my own productivity.  Instead of drag and drop and changing properties, now I am coding XAML, blindly, not knowing what it does or why.  Pasting copied XAML and trying to get it to work.  Is there any training plan for learning XAML and WPF?  I am not getting it?  Every page I find in the MSDN is too many lines long and windy and lofty and complex.  Guys are suggesting inheritance hierarchies for the ViewModels and I cannot even get a simple ViewModel to bind and display.

Please help.

Coordinator
Mar 24, 2012 at 11:09 PM

those are alot of questions.  As you have noted there is alot of long winded stuff online and is in part what caused this long forgotten project to be created.  Initially it was called something else but there was a lot of negative feed back about the name as we called it MVVM for Tards as a protest to all the long winded intellectual potification on the subject.  In any case really to use Simple MVVM you need to understand WPF first or its still going to be a hard process to wrap your mind around.  once that it done then wpf increases productively signficantly and allows designs and developers to work on the same code at the same time increasing productive further while improving the general ux and helps prevent developers from building UI which they are terrible at.

so your questions in order:

there is a complete working sample in the zip but basically a view is loaded on the screen, it gets its data from a view model which gets its data from a model which magically knows how to get data from some place that none of the other objects care about.  The vm's job is to present the data to the view in such a way as to be able to be databound and to update all the other properties via the implementation of INotifyPropertyChanged.

Generally I'll rename the default page in a silverlight or wpf project from 'MainWindow.xaml' Shell.xaml and update app.xaml.cs to point at that.  I use a top level window as shell to manage animation between views or default chrome etc.  Then users controls generally as views so they can be animated between better and there is more decreet control over them but you could do it really anyway you want.  really you need to understand wpf generally before getting into mvvm and databinding THEN it will help you be more productive. 

Well order of execution can be different in properties and INotifyPropertyChange normallizes this.  From the view standpoint.  the window or shell will load the view which during its render it will call on static members of the vm (you need to make sure you are not using constructors on vm classes or view class's or they wont' work in blend and in some other cases) from each binding the vm is first which will call the model property to get the value.

userControl is used as a construct for a view so you have a top level window or shell that can control transitions between views.  If you use a window you loose the ability todo the best transitions and some state values don't go between window threads well (at all).  And ideally you should understand it not just cut and paste.

yes you could draw a UML model but it would be more complex then you might think...

Really if you don't understand wpf the code files in vs are not going to entirely make sense up front.  learn wpf or silverlight or phone 7 or windows 8/winRT etc.

yes, xaml is not a 'programming' language is a UI markup language.  maybe trying using blend to see how xaml is rendering and play with dragging elements on the the design surface and then open it in vs or opent he blend code view to see what happens?  you can think of xaml as being kind of like html