In this article I am going to walk through an application using WPF and Prism (aka composite application guidance, CAG) which simulates engaging a taxi (cab).
The rules are simple, the app would have3 screens
- A login screen to authenticate the user
- An information screen.
- A screen to engage the cab and roam around and calculating the total fare
Metered Rate of Fare
The meter is required to be engaged when a cab is occupied by anyone
$3.00 upon entry
$0.35 for each additional unit
The unit fare is:
- one-fifth of a mile, when the cab is traveling at 6 miles an hour or more; or
- 60 seconds when not in motion or traveling at less than 12 miles per hour.
- Night surcharge of $.50 after 8:00 PM & before 6:00 AM
- Peak hour Weekday Surcharge of $1.00 Monday - Friday after 4:00 PM & before 8:00 PM
- New York State Tax Surcharge of $.50 per ride.
- Friday (2010-10-08)
- Start at Lexington Ave & E 57th St
- End at Irving Pl & E 15th St
- Start = $3.00
- Travels 2 miles at less than 6 mph for 15 minutes = $3.50
- Travels at more than 12 mph for 5 minutes = $1.75
- Peak hour Weekday Surcharge = $1.00 (ride started at 5:30 pm)
- New York State Tax Surcharge = $0.50
Before we dive into the app, I would like to give brief description about the framework. If you want to jump on to the source code, scroll all the way to the end of the post.
MVVM pattern is in no way related to the usage of PRISM in your application and should be considered if you are using WPF irrespective of PRISM or not.
Lets say you are not familiar with MVVM, your typical UI would involve adding some UI controls like text boxes, a button, double clicking on the button, generating event handler, calling a method from business layer and updating the user interface, it works most of the time for developing small scale applications. The problem with this approach is that there is some amount of code specific to business logic wrapped in UI specific code which is hard to unit test it, mock it and MVVM helps to solve the exact problem.
MVVM stands for Model(M) – View(V) – ViewModel(VM), based on the interactions with in the three parties it should be called VVMM, MVVM sounds more like MVC (Model-View-Controller) so the name.
Why it should be called VVMM: View – View Model - Model
WPF allows to create user interfaces using XAML and MVVM takes it to the next level by allowing complete separation of user interface and business logic.
In WPF each view will have a property, DataContext when set to an instance of a class (which happens to be your view model) provides the data the view is interested in, i.e., view interacts with view model and at the same time view model interacts with view through DataContext. Sujith, if view and view model are interacting directly with each other how does MVVM is helping me separation of concerns? Well, the catch is DataContext is of type Object, since it is of type object view doesn’t know exact type of view model allowing views and views models to be loosely coupled.
View models aggregate data from models (data access layer, services, etc) and make it available for views through properties, methods etc, i.e., View Models interact with Models.
Prism is used to build composite applications, the framework is provided by Microsoft Patterns and Practices team and it can be downloaded from codeplex for source code, samples and documentation on msdn. The name composite implies, to compose user interface from different modules without direct dependencies on each other, again allowing loosely coupled development.
Well Sujith, I can already do that with user controls, why shall I learn another framework? That’s correct, you can decouple using user controls, but you still have to manage some amount of coupling, like how to do you communicate between the controls, how do you subscribe/unsubscribe, loading/unloading views dynamically. Prism is not a replacement for user controls, provides the following features which greatly help in designing the composite applications.
- Dependency Injection (DI)/ Inversion of Control (IoC)
- Event Aggregator
Simply put, MVVM helps building a single view and Prism helps building an application using the views
There are other open source alternatives to Prism, like MVVMLight, Cinch, take a look at them as well.
Lets dig into the source code.
The solution is made of the following projects
- Framework: Holds the common functionality in building applications using WPF and Prism
- TaxiClient: Start up project, boot strapping and app styling
- TaxiCommon: Helps with the business logic
- TaxiModules: Holds the meat of the application with views and view models
- TaxiTests: To test the application
2. DI / IoC
Dependency Injection (DI) as the name implies refers to injecting dependencies and Inversion of Control (IoC) means the calling code has no direct control on the dependencies, opposite of normal way of programming where dependencies are passed by caller, i.e inversion; aside from some differences in terminology the concept is same in both the cases.
The idea behind DI/IoC pattern is to reduce the amount of direct coupling between different components of the application, the higher the dependency the more tightly coupled the application resulting in code which is hard to modify, unit test and mock.
Initializing Dependency Injection through BootStrapper
TaxiClient is the starting project of the solution and App (App.xaml) is the starting class that gets called when you run the application.
From the App’s OnStartup method we will invoke BootStrapper.
BootStrapper is your contact point for initializing the application including dependency injection, creating Shell and other frameworks. We are going to use Unity for DI and there are lot of open source DI frameworks like Spring.Net, StructureMap etc with different feature set and you can choose a framework based on your preferences. Note that Prism comes with in built support for Unity, for example we are deriving from UnityBootStrapper in our case and for any other DI framework you have to extend the Prism appropriately
Lets take a look into FrameworkBootStrapper to check out how to register with unity container.
In the above code we are registering two components with unity container. You shall observe that we are following two different approaches, RegisterInstance and RegisterType. With RegisterInstance we are registering an existing instance and the same instance will be returned for every request made for IDispatcherService and with RegisterType we are requesting unity container to create an instance for us when required, i.e., when I request for an instance for IInjectSingleViewService, unity will create/return an instance of InjectSingleViewService class and with RegisterType we can configure the life time of the instance being created. With ContaienrControllerLifetimeManager, the unity container caches the instance and reuses for any subsequent requests, without recreating a new instance.
Lets take a look into FareViewModel.cs and it’s constructor. The constructor takes one parameter IEventAggregator and if you try to find all references in your solution for IEventAggregator, you will not find a single location where an instance of EventAggregator is passed directly to the constructor. The compiler still finds an instance and works fine because Prism is already configured when used with Unity container to return an instance of EventAggregator when requested for IEventAggregator and in this particular case it is called constructor injection.
Shells are very similar in operation to Master Pages in asp.net or MDI in Windows Forms. And shells contain regions which display the views, you can have as many regions as you wish in a given view. You can also nest regions. i.e, one region can load a view which in itself may contain other regions.
We have to create a shell at the start of the application and are doing it by overriding CreateShell method from BootStrapper
From the following Shell.xaml you shall notice that we have two content controls with Region names as ‘MenuRegion’ and ‘MainRegion’. The idea here is that you can inject any user controls into the regions dynamically, i.e., a Menu User Control for MenuRegion and based on the user action you can load appropriate view into MainRegion.
Prism provides the ability to build composite applications and modules play an important role in it.
For example if you are building a Mortgage Loan Processor application with 3 components, i.e. customer’s credit history, existing mortgages, new home/loan information; and consider that the customer’s credit history component involves gathering data about his/her address, background information, job details etc. The idea here using Prism modules is to separate the implementation of these 3 components into their own visual studio projects allowing to build components with no dependency on each other and independently. If we need to add another component to the application, the component can be developed by in house team or some other team in the organization by starting with a new Visual Studio project and adding to the solution at the run time with very little knowledge about the application.
Prism modules are defined by implementing the IModule interface and each visual studio project to be considered as a module should implement the IModule interface. From the BootStrapper.cs you shall observe that we are overriding the method by returning a ConfiguratingModuleCatalog which returns the modules that are registered for the application using the app.config file and you can also add module using code.
Lets take a look into configuration file.
Here we are adding TaxiModules project to our solution and TaxiModules.ModuleInitializer implements IModule interface
5. Module Mapper
With Prism modules you can dynamically add or remove modules, apart from that Prism also provides API to control adding/removing the views from a region.
Taxi Information Screen:
Engage the Taxi Screen:
The sample application has two screens, ‘Taxi Information’ and ‘Engage the Taxi’ and they both reside in same module, TaxiModules. ‘Engage the Taxi’ is again made of two user controls, FareView on the left and TotalView on the right. We have created a Shell with two regions, MenuRegion and MainRegion with MenuView loaded into MenuRegion. We can create a wrapper user control called EngageTheTaxiView made of FareView and TotalView and load either TaxiInfo or EngageTheTaxi into MainRegion based on the user action. Though it will work it tightly binds the user controls and for every combination of user controls, we need to create a dummy wrapper control to contain them. Instead we can apply the principles we learned so far from Shell/regions and introduce another template (LeftAndRightRegionView.xaml) made of two regions Region1 (left) and Region2 (right) and load FareView and TotalView dynamically.
To help with loading of the views dynamically I have introduce an helper an interface, IInjectSingleViewService, idea suggested by Mike Taulty, a must read blog for .Net developers.
The Interface declares three methods to work with views:
- RegisterViewForRegion: Registers a view with a particular region. You can register multiple views and their regions under one command. When this particular command is invoked all the views registered under it will be loaded into their regions.
- ClearViewFromRegion: To unload a specific view from a region.
- RegisterModule: The idea is when a command is invoked you can load the UI with set of controls in their default position and based on the user interaction, you can load different contols in to different regions on the fly. And it is supported ModuleViewDefinition and ModuleMappers as shown below.
6. Event Aggregator
Prism event aggregator enables messaging between components as in Observable pattern, Notifier notifies the Observer which receives notification it is interested in.
When it comes to Observable pattern, Observer has to unsubscribes for notifications when it no longer interested in notifications, which allows the Notifier to remove the Observer’s reference from it’s local cache. Though .Net has managed garbage collection it cannot remove inactive the instances referenced by an active instance resulting in memory leak, keeping the Observers in memory as long as Notifier stays in memory.
Developers have to be very careful to unsubscribe when necessary and it often gets overlooked, to overcome these problems Prism Event Aggregator uses weak references to cache the reference (Observer in this case) and releases the reference (memory) once the instance goes out of scope.
Using event aggregator is very simple, declare a generic type of CompositePresenationEvent by inheriting from it.
TaxiOnMove.cs includes the properties which we want to exchange between the parties, FareView and TotalView.
Lets take a look into FareViewodel (Notifier) and how it raises the event. Here we are raising the event by getting the event through GetEvent<..>() and publishing it with the payload
And TotalViewModel(Observer) subscribes to notifications by getting the event through GetEvent<..>()
7. MVVM through example
In this section we are going to look into MVVM implementation through example. I have all the modules declared in a single project, TaxiModules, again it is not necessary to have them into one project.
Once the user logs into the application, will be greeted with the ‘Engage the Taxi’ screen which is made of two user controls, FareView.xaml and TotalView.Xaml. As you can see from the solution explorer, each of them have their own code behind files and ViewModel classes, FareViewMode.cs, TotalViewModel.cs
Lets take a look in to the FareView and how it interacts with FareViewModel using MVVM implementation. FareView.xaml acts as a view and FareViewMode.cs is it’s view model.
The FareView code behind class
The FareView is bound to FareViewModel through the data context and you shall observe that DataContext is of type Object, i.e. the FareView doesn’t really know the type of ViewModel (FareViewModel). This helps separation of View and ViewModel as View and ViewModel are independent of each other, you can bind FareView to FareViewModel2 as well and the application compiles just fine.
Lets take a look into FareView xaml file
The highlighted code from the above code shows data binding, for example ComboBox which displays list of states has it’s ItemsSource bound to States property, with DataTemplate bound to Name and SelectedItem to SelectedState. You might be wondering what are all these properties and how it is able to bind to them. The answer lies in data context, i.e., when you bound a control, WPF looks for data context on the root object (Grid in this case) and if it can’t find data context it will look into root’s root, i.e. FareView UserControl and it is bound to FareViewModel. Each of those properties have be declared on the ViewModel for the View to bind correctly.
To put simply, View is bound to ViewModel through data context of type object and every control that is bound on the View actually binds to the public property on the ViewModel.
Lets look into the ViewModel code (the following code is not an exact copy of FareViewMode.cs, pasted relevant code for this section)