Question

Finally getting to do some Silverlight development and I came across MVVM. I am familiar with MVC and the article I was reading said because of XAML, MVC would not work out. Not having too much experience in XAML clearly is the reason I did not get this point.

Can someone explain why MVC is not suited and why MVVM is better for Silverlight development?

Thanks
JD

Answer 1

Its a very slim distinction, which I can explain best by comparing MVC in ASP.NET and MVVM in WPF.

In ASP.NET MVC the request comes in from the web server and is handled directly by the Controller. The Controller determines the appropriate View and populates it with Models. The Controller then releases these instances to the underlying system which renders a result to the client. You can see that the Controller is first and last to act.

In MVVM, the UI (the View), faces the user and takes user input directly. Within the View, Commands within the ViewModel (which is the DataContext of the View) are triggered by this activity. Control flows to the ViewModel which interprets what the View has sent it and prepares its Models. After control flows back to the View it updates itself according to changes in the Models. If a new View is required, the ViewModel communicates this with the NavigationService (or whatever method of navigation your application uses), which is the purview of the Window or Frame–UI components. You can see that the ViewModel isn’t first and last to act; the View plays a much greater role than in MVC.

The architecture of WPF/Silverlight is the reason why things are done this way. The command, binding and navigation infrastructures can’t be controlled/replaced by the Controller; they are tightly integrated with the UI. So the Controller must sit below the View and take a more passive role.