First, let’s briefly cover what MVVM is about for those of you who don’t know yet. MVVM virtually eliminates all of the code that would typically be placed in the code-behind file of your View (a user control, a screen, whatever) by putting all of that logic in the ViewModel. The ViewModel itself is never tightly coupled to the View. If it does have a reference to it, it’s typically through an interface that the View implements instead of a reference of the actual type of the View. This increases, or better yet, introduces testability to a large part of your UI code that you normally wouldn’t be able to cover with unit tests if you’d go with the traditional “put it all in the code-behind”-approach.

The ViewModel typically contains properties for the data that is to be shown in the View, and also raises notification events when the data in those properties changes. The View uses the powerful data-binding capabilities of Silverlight/WPF to bind the properties of the ViewModel to other user controls that the View is composed of. User-events that are captured by the View are sent to the ViewModel through Commands. Typically, these commands execute a method in the ViewModel which contains some kind of logic… usually to either send the updated data in the ViewModel’s properties to the Model (usually a Service Layer in Silverlight, in WPF it could be either a true Domain Model or also a Service Layer), to perform some business logic in the Model, or to retrieve data from the Model so it can be placed in the ViewModel’s properties so the View can bind to it.

That is, in a nutshell, how the MVVM pattern works. So why do i have issues with this? You can develop and test most of the application’s logic without being dependent on a physical View and that is typically a Good Thing, no? It sure is! However, my problem with this approach is that too many responsibilities are concentrated within the ViewModel. Its main responsibilities are to facilitate databinding and to interact with the Model. And that, in my opinion, isn’t very clean. In some ways, you could actually think of the ViewModel as a glorified code-behind, with the only difference being that it’s not tightly coupled to the (physical) View.

In most (if not all) MVVM implementations, a ViewModel has many possible reasons to be changed. It might need to be changed because of different data-binding requirements. Then again, it might also require changes when a part of the Model is modified. Now, i’m sure many of you can agree with me when i say that two of the most important principles in software development are Seperation of Concerns (SoC) and the Single Responsibility Principle (SRP). Obviously, the ViewModel doesn’t fare well when it comes to both of these principles.

Lets forget about MVVM for a second and focus on the concerns and responsibilities that a user control can have… say, a user control that shows customer information and allows the user to edit that data so it can be persisted:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• communication/interaction with the Model
• making data (from the Model) available so it can be displayed
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc…)

Without MVVM, all of these would be taken care of in the View. Obviously, not a good idea right? After all, if it were a good idea, we’d never have had a reason to start using MVVM in the first place.

Now, with MVVM, a lot of people would divide these concerns and responsibilities like this:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc…)

ViewModel:

• communication/interaction with the Model
• making data (from the Model) available so it can be displayed

In this case, the View still has 3 responsibilities which is still too much according to ‘the guidelines’, but it’s not that big of a deal (though plenty of people would argue that the simple validation would be better placed in the ViewModel). You’re highly unlikely to actually want to write automated tests for pure visualization anyway and the SRP is not something that you absolutely need to follow to the extreme in every single place. For the View, this is really not a problem and very much acceptable.

The ViewModel however has 2 important responsibilities in this case, and i’d argue that these 2 things should not be done in the same place. Making data available is done through data-binding. To do this, you need a set of properties and you need to raise the necessary events. In most cases, raising those events is very straightforward, but in more complex controls you might need a bit of additional logic to determine which event should be raised at what point. The other important responsibility is the communication/interaction with the Model. In most Silverlight applications, the Model will be a Service Layer. To communicate with this Service Layer, you need Service Proxies. That means that your ViewModel is essentially responsible for communicating with the Service Layer, dealing with business exceptions that might be thrown by some service calls, and dealing with technical exceptions that can occur simply because of network-related problems. Group all of those together and i don’t think i’m going out on a limb here by saying that that is a lot of logic to put in one class, no?

(Sidenote: what i don’t really understand is that many people who vigorously advocate adherence to SRP and SoC in their domain and business code don’t seem to hold their UI code to the same standards. I do.)

At work, we do a lot of Silverlight development. We typically have around 5 Silverlight projects in active development at the same time. And it’s been that way for over a year now. That equals a lot of Silverlight code that we’ve written and experience and knowledge that we’ve built up. And we haven’t used MVVM for any of it. All this time, we’ve been using the MVP pattern (Supervising Controller variant) with a slight twist. That twist being a slimmed down version of a Presentation Model. Our Presentation Model’s sole responsibility is to facilitate data-binding, and in some cases, a touch of validation is added as well.

If we go back to our previous example of the customer screen, the responsibilities and concerns would be divided like this in our MVP-PMlight approach:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc…)

Presenter:

• communication/interaction with the Model based on the contents of the Presentation Model

Presentation Model:

• making data (from the Model) available so it can be displayed

Which leads to classes which are more focused on their task instead of trying to focus on too many things at the same time. In my opinion, this approach is much better/cleaner than MVVM. Not only is there a noticeable benefit in code quality (classes are more focused), there is also increased potential to reuse our ‘light Presentation Models’ in multiple controls. Testability is increased over MVVM as well since it’s always easier to test classes which are focused versus testing classes which have too many responsibilities. All in all, a couple of important benefits and we still haven’t thought of a real drawback compared to MVVM.

Those are Silverlight tests, executed through Resharper within the Silverlight runtime

Check out the movies, and if you want a bit more information on what these applications do, just click here.

CRM from itemsolutions on Vimeo.

Genesis from itemsolutions on Vimeo.

Glance from itemsolutions on Vimeo.

Emmaus from itemsolutions on Vimeo.

Synergy from itemsolutions on Vimeo.

Nokeos from itemsolutions on Vimeo.

This is something that Steven De Kock and Tom Ceulemans (two coworkers of mine without a blog, so no link) have been working on.  Those are Silverlight tests, executing in the Silverlight runtime, within a full browser context.

And yes, they will release it as an open source project soon

First of all, you need to make sure that your IIS installation has support for Windows Authentication. Go to Add/Remove Programs (appwiz.cpl), click on Turn Windows Features on or off, select Internet Information Services – World Wide Web Services – Security and make sure that Windows Authentication is checked.

Next, you need to make sure that the virtual directory where you’re hosting the WCF service has Windows Authentication enabled. Open Internet Information Services Manager (inetmgr), select the virtual directory where the WCF service is hosted, click on the Authentication icon and enable Windows Authentication.

After that, you need to add the following to the binding configuration of the service endpoint (in the host, obviously):

I only got it working with basicHttpBinding, so unfortunately i can no longer use the customBinding to use binary XML…

In your Silverlight project, open the ServiceReferences.ClientConfig file and add the following to the binding configuration:

After that, you should be able to do this in your WCF service:

And that should return the Windows user of the user running the Silverlight client.

For the record: this is with Silverlight 3… i have no idea if it’ll work with Silverlight 2

But these views do have to interact with each other. I didn’t want to use typical events because that would require either a certain view to know about another view to be able to subscribe to its events, or you’d need some other component which knows which views need to be hooked to each other. We really need maximum flexibility for what we have in mind with our views, so it only made sense to finally start using the Event Aggregation pattern. The idea is that a view can basically publish events, without knowing who is subscribed to these events, and that suscribers will be notified whenever these events occur. However, subscribers don’t know anything about who is publishing the events. Instead, both publishers and subscribers only know of the Event Aggregator. A publisher tells the aggregator to publish an event to all subscribed listeners for that event. Each subscribers simply tells the aggregator “i’d like to be notified whenever this event occurs, and i don’t care where it comes from”.
Plenty of implementations of this pattern can be found online already, so i figured: why not add my own? :p

Fist of all, an event is nothing more than a class that inherits from this class:

Every event should inherit from this class, and add whatever necessary properties that are important for that particular type of event.

If a class is interested in listening to a specific event, it needs to implement the following interface:

If a class is interested in multiple events, it simply needs to implement the generic IListener interface for each type of event that it wants to handle.

Then we obviously need the Event Aggregator. I wanted an aggregator that allowed listeners to either subscribe/unsubscribe to/from very specific events, or just subscribe/unsubscribe to/from whatever it supports. So i have the following IEventAggregator interface:

The Subscribe and Unsubscribe methods that simply take an IListener reference will either subscribe or unsubscribe the given listener to/from every event that it can handle. In other words, for every generic IListener interface that it implements. Yet you also have the ability to subscribe/unsubscribe from a specific event type.

And here’s the implementation:

In case you’re wondering… the IDispatcher interface is merely a way to wrap Silverlight’s real Dispatcher. We wrap it so we can use a different implementation of the IDispatcher in our automated tests. Other than that, the implementation is very straightforward.

We started using this very recently, so this implementation might change in the upcoming weeks, but for now it does what it needs to do and it does so pretty well. In our case, every view’s Presenter automatically has an IEventAggregator property so whenever we need to publish an event, we can simply do something like EventAggregator.Publish(new SomeEvent(someParameter)). Or, Presenters that need to listen to events can simply say EventAggregator.Subscribe(this) or only subscribe to some specific events whenever they need to and their specific Handle method will be called whenever someone publishes the event. This also allowed us to get rid of the somewhat awkward syntax when testing events (subscription, unsubscription and the actual handing of events) with mocking frameworks.

And as a last bonus, i put a call to the Unsubscribe(IListener) method in the Dispose method of our base Presenter implementation. Which means that none of them will be left subscribed to events by accident anymore

While i generally don’t get involved in most of the UI stuff, i’m pretty happy with this because i seriously like Silverlight as a platform. Below is my list of top 5 reasons why Silverlight is my preferred platform for Web Development nowadays:

1. The ability to create an excellent UIX which definitely matters to customers.

   We have some projects at work where the Silverlight UI definitely receives a “wow” response from customers. Not only because the UI is extremely responsive and snappy, but also because we can use new ways of visualizing data and enabling user actions in the UI in ways that are either completely new for web applications, or just new in general. We can easily create much more intuitive user interfaces with a responsiveness that can easily compete with that of desktop applications.

2. Low bandwidth overhead

   Downloading the XAP file can sometimes be painfully slow, depending on your bandwidth obviously, but once it’s downloaded it’s also cached by the user’s browser. Everything that happens after that consumes very little bandwidth. There is no CSS, no HTML markup, no javascript, … the only thing that goes over the wire is the data that you actually need. And with Silverlight’s Binary XML feature you’re also using less bandwidth than before. This might not seem like a big deal to you, but bandwidth has a huge impact on the client-side responsiveness as well as your server-side ability to process requests.

3. The client is stateful again

   This one is huge to me. We don’t have to deal with things like ViewState or SessionState or anything like that. If a client has retrieved a set of data, it can just keep it in memory if it makes sense to do so. This is especially useful for things like user-profiles, or static data that never changes but it has an impact on pretty much everything you develop. You can simply keep whatever data you need in memory, and it has no impact on the server at all. Well, it actually reduces the amount of data that you need to send to the server (or receive), and the number of requests you need the server to handle to implement the functionality you need client-side. This is pretty much a win-win for both the client and the server whereas with typical ASP.NET development, either the client or the server has to take some kind of a hit when it comes to maintaining state (even if it’s only a little).

4. The ability to write the client almost entirely in C#

   I don’t know about you, but my HTML, CSS and Javascript skills are extremely limited. This seriously reduces my effectiveness when i need to make changes in the presentation layer in typical ASP.NET applications. And while my XAML skills aren’t what they should be, my C# skills are sufficient for me to be effective in client-side changes. I can easily look at a piece of client-side code and make whatever change i need to make without having to consult a reference guide. That’s not the biggest advantage to being able to write the client in C# though. Existing C# skills are very easily transferable to the Silverlight side of things, which means that a larger pool of developers is available to work on your front-end. True, there is a bit of a learning curve when it comes to Silverlight, but i’d argue that there is a much steeper learning curve to doing traditional client-side web development effectively.

5. It’s only going to get better

   As much as i like Silverlight, it is by no means perfect and there is plenty of room for improvement. That’s normal though for such a young platform. In the future we’ll see plenty of new libraries and tools that will become available to Silverlight developers which should enable us to create even better web applications. Microsoft is investing a lot of money and effort into it, and i’m pretty sure that others will follow.

Now, you won’t hear me say that Silverlight is the perfect solution for every web application. SEO is still a problem, as well as acceptance of the Silverlight plugin in corporate environments (though this will only improve over time). But, in the situations where you can use Silverlight, it certainly pays off to do so.

I wrote a very simple Silverlight application which has a rather typical memory leak. Here’s the actual code:

For some of you, the memory leak is already very clear. Like i said, it’s a very simple example

Let’s go through the process of finding and fixing the memory leak using WinDbg. First of all, download Debugging Tools For Windows (which contains the WinDbg executable) here and install it.

Then we start our application in Internet Explorer (for some reason i can’t use WinDbg to inspect the managed memory heap with Firefox, so i just use Internet Explorer for this stuff) and use it. In the case of my example, that means clicking the button which creates a new view a couple of times.

Open WinDbg.exe and select the ‘Attach to a Process’ menu item in the ‘File’ menu and select the iexplore.exe process.

Then you need to load the correct version of sos.dll:

After that we can see which types of our MySilverlightApplication namespace are present in the managed heap, including how many instances of them:

As you can see, there are 13 instances of our MyView type present in the heap. Using the value in the MT column, we can drill down further:

This shows the memory address of each instance of the MyView type in the heap. Now we can see if there are any live references to these instances:

This is actually for the first address that was listed. As you can see, it is still a reachable reference, which means it will not be collected by the garbage collector. The chain of references clearly indicates that the instance is still referenced from our event in the MainPage instance. All of the previously listed instances show the same reference chain, so this is clearly a memory leak. Even though we should only have one active reference of MyView at any point in time of this application, the MyEvent event on MainPage clearly keeps each instance of MyView alive.

The correct way to fix this is to make sure that whenever we remove an instance of MyView, we need to unsubscribe it from the MainPage’s MyEvent handler. Always remember this rule when it comes to dealing with events: if the publisher of the event has a longer lifetime than the subscriber of the event, then you absolutely have to unsubscribe each subscriber from the event or the publisher will keep references to each subscriber (preventing them from being garbage collected) for as long as the publisher is alive.

Here’s the modified version of the above code which avoids the memory leak:

Let’s see if this really fixed the memory leak. If we fire up the application and press the button a couple of times, the application should normally only have one live reference of MyView in memory.

I clicked the button 5 times, and the above output shows that there are 5 instances of MyView on the heap. So did we fix the leak or not? Check the output below:

As you can see, only the last instance of MyView is actively referenced somewhere. That means that the first 4 instances are ready to be collected during the next garbage collection.

One thing i don’t understand though, is that the reference chain of the last instance doesn’t mention MainPage or the event handler anymore. But when i attached Visual Studio’s debugger to the browser instance i could clearly see that the MyEvent of MainPage indeed contained an event handler that pointed to this MyView instance. I’m far from a WinDbg and SOS expert so i have no idea why the reference chain doesn’t reflect this. Perhaps someone with more WinDbg and SOS knowledge can shed some light on this?

Either way, this approach is a pretty good way of finding memory leaks in your Silverlight code. In a real application it’s obviously a bit more complicated to find the exact cause of a leak compared to this simple example, but it’s still pretty doable. Just execute the !dumpheap -stat -type YourRootNameSpaceHere and look for unusually high numbers of instances of your types. Then you can start looking at each instance to figure out what’s going on. And for a nice list of commands that you can execute in WinDbg with SOS, be sure to check this out.

Also, keep in mind that you can do this for every .NET process, and not just Silverlight. Though you would need to load the sos.dll file of your particular .NET version.

We already have a base PresentationModel which has the following method:

We also have a generic PresentationModel class which inherits from this class:

Notice that you pass an expression to the NotifyPropertyChanged method. It can be used like this:

That’s pretty cool, but you should be able to test this easily, right? That’s pretty easy to do as well:

There we go… no more strings so refactoring won’t break anything, and it’s easy to test as well.

In the past i have resorted to grabbing a memory dump of the browser and analyzing the content of the managed heap with windbg to track down which instances where being kept in memory. While this works, it’s pretty time consuming and can quite easily lead you down the wrong path. One of the most important things that you want to know in this specific case is: which types are being kept in memory, and how many of them?

In this case, being able to query something during debugging regarding which instances are still kept alive in memory at certain times is sufficient for me. So i came up with the following class:

The idea is basically to just keep a list of WeakReferences of objects you want to track (only if a debugger is attached), and later on you can ‘query’ the live instances through the GetAllLiveTrackedObjects method. This method obviously performs a full garbage collect to make sure only objects that are really still alive are returned. Again, you should almost never do a GC.Collect() manually, but in this case the method will only be called while you’re debugging.

Then, you strategically put the following line in the constructor of every kind of type you’d like to track:

I have that line in the constructor of my base View class, my base Controller class and in my base Disposable class. So now, when i want to check if there are any dangling references to instances of types that i really don’t want hanging around, i can just do something like this:

And then manually inspect the content of the liveObjects collection. It’s far from perfect, but at least it’s an easy way to at least know which instances (that i care about) are being kept in memory. It’ll do until we get better tool support :p

The general idea is to be able to implement each client application in its own Silverlight Application Project, and to have the ability to download each client aplication’s XAP file into the Host application and display it within the designated visual area for the currently active client application.

First, we need an interface that each client application needs to contain an implementation of:

The VisualContainer property needs to return a UIElement which is basically the main visual container element of the client application. This could be its main page or just a grid or just about any graphical component.

Then we need a class to download XAP files based on their URI. Since you have to do all of these things asynchronously in Silverlight, and the generally used approach seems to be the event-based async pattern, i use the following base eventargs class for all of my asynchronous operations:

And then we have the DownloadCompletedEventArgs class:

Now we can write our simple FileDownloader class:

We also need something to extract the assemblies from a downloaded XAP file:

And then we can write a class which can retrieve the type which implements the IClientApplication interface from a downloaded XAP file:

Obviously, this code doesn’t deal with the possibility of multiple or no IClientApplication implementations within the same XAP file. Not really relevant for this post though

And now, we can simply do something like this within our host application:

and the LoadCompleted event handler could look like this:

And that’s all there is to it.

Update: download a sample of this here.

In the output folder of the Silverlight project, you can clearly see that the Our.KickAss.Silverlight.Project.resources.dll file is located in the ‘nl’ folder. The XAP file that is being copied to the actual web project however, doesn’t contain the dutch resources.

Apparantly, the key to ‘fixing’ this is opening the .csproj file of your Silverlight project, and then you need to modify the SupportedCultures element so it contains the cultures you’re supporting:

There might be a way to do this from the UI within Visual Studio, but i sure didn’t find it anywhere.

And now you can simply switch between the translations setting the generated resource class’s static Culture property to the culture you want, for instance:

The new out of browser experience in Silverlight 3 enables users to place their favorite Silverlight applications directly onto their PC and Mac, with links on the desktop and start menu—all without the need to download an additional runtime or browser plug-in.

So we can create .NET applications that run on the Mac now

Sure, they’ll be sandboxed and you can’t do everything a real native application could do, but this could still be a pretty compelling deployment choice.

So i started looking into the usual things: making sure disposable instances where disposed of properly, that evenhandlers were unregistered properly, etc. I went over the code and it seemed to be alright. Stepping through the code with a debugger verified that disposables were indeed disposed of, and that all event handlers were unregistered.

So why was pretty much everything kept in memory? Further research with windbg showed that every ProgressBar instance that was ever created (and we use a lot of them, basically every time we make a call to the application server) kept a reference to the UserControl it was placed on and thus, kept the UserControl and all the references it contained alive. In our case, that includes our presentation models and obviously all of the contained child UserControls.

The ProgressBar is defined like this:

The key here is the usage of the IsIndeterminate property… setting this to true causes the ProgressBar to move continuously without respecting any current Value property. You know, basic stuff. The thing is… if i change the definition of the ProgressBar to this:

The memory leak suddenly went away

Obviously, this isn’t a solution because the ProgressBar now doesn’t really indicate any progress and we need our kick ass custom animation to retain the coolness of the application.

So for some reason, when you set the ProgressBar’s IsIndeterminate property to true, it actually keeps all of its references alive even when the ProgressBar control is removed from its parent control. Happy times.

We now have the following ugly method in one of our base UI classes:

But it appears that the people who feel this way about Silverlight’s future are in the minority. You don’t see a lot of the really big name .NET bloggers talking about Silverlight (although there are a few), though i’m hoping that will change over time. In the meantime, i’d like to know what you think Silverlight’s future will look like. I’ve put up a new poll with the following possible answers:

• It’s never going to take off in a meaningful way
• It might pick up some steam for media-related purposes, but that’s about it
• It will pick up more adopters as the platform matures and offers more out-of-the-box capabilities for typical business applications
• It’s too different from traditional web development to appeal to most web developers
• It will reach wide adoption, but never more than that of typical web apps
• Someday it will be the default development platform for .NET web developers

(NOTE: for those of you reading this through the RSS feed, the poll is only accessible on my site and is located at the top right corner of the page)

There will obviously be some missing options, so feel free to point them out in the comments. I’m looking forward to the results and your thoughts on this topic