Silverlight 3 MVVM Project Part I (updated Architecture)

I know things in IT change fast, but I didn’t know things could change this fast. As soon as I posted my previous blog on the Silverlight 3 MVVM Architecture, it was already outdated. So here is the update.

We decided that because we use bindings to get a reference to the commands, the commands are actually a part of the viewmodel. So the updated architecture looks like this:

A View implements an interface, this is a change on the previous model. For a composite application I don’t want to implement a hard dependency on a specific kind of view.

For example: Let’s say I have a module that allows me to search for a person (SearchPersonModule) and I have another module that allows me to search for cars (SearchCarModule). If I want to use these modules on PersonView and CarView, I would have to specify which module I want to load (hard dependency). This means I’m using my modules as UserControls. This can be a good idea, but it defies the purpose. I’m trying to take it a step further. The SearchPersonModule and SearchCarModule both implement the same interface (Let’s call that ISearchModule). In the PersonView and CarView I now only have to specify that I want a module that implements ISearchModule and leave it up to the Application or IoC container to give me an instantiated version of the right module. (I’ll describe how this is done in the next part of this blog)

A View only has one ViewModel, everything a View needs to know is in that ViewModel (or the ViewEntities). A View can contain other Views and those Views will have their own ViewModel. The ViewModel also creates the Commands for the View, I explained how we use Commands my previous post. The ViewModel is also responsible for any view-specific functions like calculating a total sum or counting the number of persons in a search result.

A ViewModel can have zero or more ViewEntities, ViewEntities are like Data Transfer Objects, they just carry the data that needs to be presented in the View.

The Model is the place where we define the information need for the module. Let’s say I need a country list, the module will request an instance of the ICountryRepository and ask for the Country list. I don’t care what is giving me the the Country list, I just want it. The implementation of the CountryRepository is not my concern. I just know that ICountryRepository has a function List<CountryDataContract> GetAllCountries(). In the model I will map the CountryDataContract to my CountryViewEntity and expose that CountryViewEntityList as a property on the model.

The IService stands for all the service interfaces I have within my application or framework (with service interface I do not mean a web service interface). For the EventManager I have an IEventManager interface and for the PersonRepository I have an IPersonRepository interface.

All the communication to and from the module will be facilitated by the Services. All the communication within the module will be done by the commands.

The next part of this blog will describe the implementation of this architecture.

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.