SILVERLIGHT, M-V-VM ... AND IOC - PART 1

Speaking of my previous post about build and IoC-enabled Silverlight Navigation framework a couple of friends of mine asked me mode details about how I implemented the MVVM pattern for a line of business application.

Model-View-ViewModel is a very simple pattern and suits very when developing with WPF and (now) Silverlight. In its ‘pure form’ the biggest advantage of this pattern is that you can develop your application engine and your application UI completely decoupled from each others and this makes your core engine completely testable.

The principle is very simple and you have lot of resources on the web to look for, but the basic idea is this:

The Model describes your application Domain, it’s a series of classes that represent your data and come from a wide range of sources (local data, databases, web services, etc..whatever you like).

The View is your application front-end, it’s the interactive portion of your application and defines the UX and the look and feel of your work.

The ViewModel acts like a mediator between the two: here you can shape and tailor the data you want to present to the user and you expose a series of functions the UI can use to interact with the data and the services. In a ‘not pure’ implementation the ViewModel can also drive the UI according to some background processing you can do on the data.

The interaction between the View and the ViewModel must happen using the less code-behind you can, ideally you should only use that the Framework already offers to you: Databinding and Commanding.

But we have also another actor to take into account: the IoC container...we plan to use an IoC container if we want to build a very modular application. The container can be whatever you like, there are lots of different implementation around: Unity, Castle Windsor, NInject, Autofac...etc...they differ in some of their advanced features, but they all offer the basic functionalities we need, so you can also ‘hide’ the actual container you use behind a wrapping interface if you need to swap it also.

Given the previous approach and the intrinsic benefit of the pattern I want to be able to switch some of the Views or some of the ViewModels based on the configuration of the container.

This is a big advantage in terms of testability and when you aren’t the only one working on the application, for example you can buildup a series of mockups of your ViewModels and configure an application that the UI designer/ UX experts can use to develop the front-end. You can also use this technique to deliver a quick and dirty ‘preview’ of some of the features your application will have.

For this reason I like to think about the contracts (interfaces) these components will expose first, it also will help me assign a specific role of them, I like to keep things simple (if I can), so I’ve started with something like this:

public interface IView
{
	IViewModel ViewModel { get; set; }
}

public interface IViewModel
{
	IView View { get; set; }

	/// <summary>
	/// a property that states the controller is busy doing something (like fetching data from a service),
	/// usually the iterface should be blocked
	/// </summary>
	bool IsBusy { get; }
}

Pretty simple and clear: this code states that a generic ‘View’ component will need a ‘ViewModel’ that will provide some data, and that a ‘ViewModel’ needs a view to make the data it holds available to the ‘outside world’. Also give a note to the IsBusy property...don’t forget we live in an asynchronous world when dealing with Silverlight applications, so we may need a way to inform the UI about the fact it has to wait for something to complete before giving the control back to the user.

Continue...

PrimordialCode

Silverlight, M-V-VM ... and IoC - part 1

Related Content

Alessandro Giorgetti