Greetings readers. This post covers some basic concepts and application principle behind MVVM pattern.

I’m assuming you have some basic knowledge of what the MVVM pattern contains, for example you should know

• ·         What a view is (UserControl)
• ·         What a ViewModel is (inherits DependencyObject and acts as the datacontext for the view)
• ·         What an ICommand is (a delegate that can be bound to via the XAML)

Etc.

My interpretation of the pattern is that the code should follow these principles:

• 1.       No Code-Behind (xaml.cs) file
• 2.       Separation of concern
• 3.       Decoupling of objects.

Let’s explore these principles

1.       No Code Behind

This is a simple idea, that all of the properties and functions that need to be exposed to the view can be pre-calculated and presented to the view in the DataContext. The view needs to make absolutely no decisions at runtime.

Where some logic is completely view specific, for example converting a string “blue” into a SolidColorBrush, you should use a converter.

There are rare cases when a control only supports some type of function in codebehind. In these cases you should implement the codebehind, but you should also ask yourself why DataBinding is not supported, since the entire Silverlight Toolkit and many other controls do support this out-of-the-box. In some cases, you may even find instructions on creating an MVVM-friendly version of the control.

2.       Separation of Concern

The ViewModel should:

·         Get Data from the service layer, model layer, or data source

·         Rework the data into any type of custom object that is needed for the final presentation

·         Filter or reorder the data down to the relevant set for viewing

·         Provide every integration point for user interaction as a Command

·         Populate DependencyProperty attributes so that they can be bound to.

The View Should:

·         Use DataBinding to display the data from the ViewModel

·         Use Converters, if necessary, to convert properties to View-Specific types.

3.       Decoupling of Objects

The ViewModel should not:

·         Access any properties of any of the View’s Controls or components or the View itself

·         Call any methods that are defined in the View’s Controls or components or the View itself

·         Throw an error if something in the View has changed (Build Error or Runtime Error)

The View Should Not:

·         Throw an error if something in the ViewModel has changed (Build Error or Runtime Error)

Resist the urge to get a reference to your Sender in the Commands!

Until next time,

Chimp

Some people have heard about the Conference where Microsoft showed their 3 screen ideal linked together using HTML 5.0.

Last year at this same event the screens were brought together with Silverlight. So this has caused a lot of hype. Is Silverlight being canned for HTML 5.0? I think not.

I think it's a miscommunication.

HTML5.0 is cross-platform. that is the point. Some people will have heard that Silverlight is supposed to be cross-platform too but they've since said that it would be impossible to have a plugin working on every single platform with the amount of devices now available to consumers. They still plan to have it working on Windows and Mac and as the software platform for Windows Phone 7.0

Silverlight is an extension for web that allows us to do custom functions based on their framework (which is a subset of .Net).

I don't believe a framework like .Net (or the JavaFx or ActionScript-based equivalents) can be replaced by a web convention such as HTML 5.0.
Any function or library in HTML5.0 would have to be supported by EVERY browser and EVERY phone. These functions need to be generic such that all web developers accross the sphere can use them.

Think about Javascript and HTML as is... The world does not use those in a uniform fashion and I don't believe they really can because that is the nature of scripts and languages.

As soon as we wish our language to be custom up to a certain point - that is, we decided that this particular code library is good enough to be packaged and distributed as a framework - we have a situation. Some frameworks aim to make everything possible using the convention such as JQuery but other frameworks are built on disparate foundations - like .Net and Java reject the web browser capability to offer a richer capability that plays through a plugin.

That is why silverlight currently exists. We want all the fancy IDE's, build tools, .Net, and all of that that has gone into it. We can't have exactly that with HTML - so there is a plugin. The bonus is that is becomes extendable. Silverlight uses TFS integration, Visual Studio 2010, Blend and other tools from Expression Studio by Microsoft. These tools have different uses and merits and are different from provider to provider. That is the great environment that RIA is giving developers.

I believe that as long as there will be third party frameworks, including the Adobe ones, the .Net and the Javas of the world, there will be framework-based RIA for web. And I'm quite certain that frameworks as a concept are here to stay.

Having said that, the size of that market for these may well change. I believe the market for Silverlight will increase as long as Microsoft and their partners can explain clearly to people: This is a way that people in my organisation or your organisation can produce software that works, works well, works easily, works on many platforms... Those benefits will still be true for silverlight 10, 11, 12 and onwards.

It is for these reasons that I think there is, and will continue to be, a line in the sand between plug-ins for RIA and base-line conventions for HTML support in browsers accross the globe.

Now all we need is for Silverlight to support Linux, Android, and all the Apple devices :(

Regards