I wanted to follow up on a previous post about learning Silverlight. As I've been creating (and refactoring) an application at work, I've used the MVVM (Model-View-ViewModel) design pattern to separate the UX (User Experience) from the data and logic of the application.

• Model - This is a "dumb" class that is just a wrapper for data properties
• View - The entire UX is contained in these classes. There is NO CODE in any of these classes, and they can be modified using design tools rather than a traditional IDE (Visual Studio).
• ViewModel - This is glue that creates Model classes (using the Service classes) and pushes that data to the View classes. I'm using a ViewModel base class to implement the INotifyPropertyChanged interface. This is the magic that monitors the data and updates the UI as data changes.
• Service - This isn't explicitly defined in the pattern, but I am using the Service classes to interact with external systems (web services, Local Storage). In addition, classes that would normally exist as a web service are deployed as local service classes (since this application is deployed as a standalone xap, with no server dependencies).

MVVM Learning Resources

• http://msdn.microsoft.com/en-us/magazine/dd458800.aspx
• http://weblogs.asp.net/dwahlin/archive/2009/12/08/getting-started-with-the-mvvm-pattern-in-silverlight-applications.aspx
• http://stackoverflow.com/questions/413451/good-silverlight-mvvm-practice-example
• http://community.infragistics.com/pixel8/media/p/91949.aspx

..... It was an exciting day in the development lab. It was a beautiful day in 2003, We had started a design spike for a new client project. This client has a secure manufacturing facility and they audited the raw material at the beginning and end of their assembly line. We didn't want to put a full PC on the floor just to audit these numbers, so we went out and bought a PDA. We wrote a proof of concept with the .NET Compact Framework and had a hands-on demo for our client to show how this project needed to have a mobile component. Fast forward, and voila, handheld devices are in the mix.....

I took you on a stroll down memory lane because this was in 2003, the .NET framework was upgraded from 1.0 to 1.1 and everything was still very new. The design spike I described above actually went as smoothly as I described. I read about two pages worth of the .NET Compact Framework documentation and put together a demo that we could sync to actual hardware. Once the client saw things running on the metal, they were sold, and the development costs were low enough that we bought extra hardware and didn't worry about the pain that is managing local devices.

Recently, I've been working on a side project to learn Silverlight. My experience has been very different from the project I listed above. The reason being that Silverlight is divergent from the .NET core libraries. Too much of my time was spent rewriting .NET libraries to be Silverlight libraries and not enough time was being spent on new features.

I really like Silverlight 4 as a RIA technology. Full trust support in networking, printing, and COM interop means that I have all of the tools I need to create rich applications. However, my bag of tricks is only half full, since the libraries that I've used on other projects will need to be recreated to be used in Silverlight. While the Silverlight 4 deployment story is great, (really much nicer than ClickOnce), the development rework required is too great in my opinion to consider Silverlight 4 for RIA development. If you are a Silverlight developer, maybe you've already crossed this bridge, but for a .NET developer trying to decide if Silverlight is appropriate, I found that the migration costs were just too high. At PDC10, Microsoft shows how to design your codebase to maximize reuse between .NET, Silverlight, and Windows Phone. I think this is exactly what would be needed for me to consider Silverlight development as a go-to solution. The issue with that is that all of the component vendors would need to design in a similar manner so that any third party components that I use can be reused in this manner. This is not the situation I see on the ground today.

To summarize, it is too expensive to "reinvent" existing codebase/applications in Silverlight. Reuse across the framework just isn't there. This post is not to declare Silverlight dead however. I've been learning a lot about the platform and I'll be posting where Silverlight IS appropriate in a future blog post. Stay Tuned!!!!

While I was taking the beta .NET 4 certification exams, I noticed a change. The Windows developer exam focused heavily on WPF and XAML (technologies I had decided to not learn). Needless to say, I failed that exam.

Fast forward a few months and I found an opportunity to work on a Silverlight application. I downloaded a demo twitter application to get started and learn the basics of what you can and can't do in Silverlight. This was good and I started adding features. Of course, before long I found myself furiously refactoring and trying to identify some best practices to separate concerns and introduce some testing to make those refactorings easier. I'm starting to learn the MVVM pattern in Silverlight and will have a followup post on that, but for now, I'm just making sure that my code falls into one of those three categories