Silverlight 3 MVVM Project Part I (Architecture)

The last two weeks I got the opportunity to make a proof of concept for a Silverlight 3 application. The best part was: there’s only one requirement! It had to use the MVVM pattern! If you’re not familiar with the MVVM pattern, then check out this wikipedia article, there you’ll find a brief explanation and some more in-depth references.

First I want to start with a “thank you” note to Marc Jacobi for the architectural guidance :). He was always there to keep that workload coming! (or change the color of that square :D)

Marc and I (mostly Marc) started on the architecture of this Proof of Concept. The end result looked something like this:

Like any MVVM application there are still the basic Model-View-ViewModel classes. I won’t explain them here. The module should be a stand alone module. All the data needed (this includes incoming / outgoing information, incoming / outgoing events) should come from a service. The module (Model, CommandActions, etc) will only request interfaces of services, this is where an IoC container is needed.

We extended the ViewModel and Model with the ViewEntity, it’s only purpose is to make the ViewModel a little bit more manageable.

Within the module we only use commands. Silverlight usually uses events like button click, but we’re going to bypass that. The Command is just the wiring for the view and the appropriate method to execute. The Command shouldn’t know anything about the actual execution of methods, only that it needs to execute something. An addition to the Command is the possibility to know if it is actually allowed to execute some method. I’ll dig into this in part II of this blog.

The CommandAction is responsible for the actual actions that need to take place when a Command is executed. The CommandAction is also responsible for registering itself to the specific Command. I’ll dig into this in part II of this blog.

To make a real composite application, we need a way to let the independent modules communicate with each other. The EventManager will make this happen. Modules can request the interface to the EventManager, the EventManager will allow the module to register itself on specific Events or to Notify other Modules of a specific Event. It’s a basic publish subscribe pattern.

That’s a wrap for the architectural point of view for the MVVM pattern in Silverlight. In the next part, I will dive into the implementation of this.