This post is part of a Prism 2 series:

Prism 2: WPF and Silverlight – Inversion of Control
Prism 2: WPF and Silverlight – Multi Platform Targeting
Prism 2: WPF and Silverlight – Modularity
Prism 2: WPF and Silverlight – Model-View-ViewModel
Prism 2: WPF and Silverlight – View Injection/View Discovery
Prism 2: WPF and Silverlight – Commands
Prism 2: WPF and Silverlight – Events
Prism 2: WPF and Silverlight – Services

One of the Prism’s strengths is it’s extensibility achieved by use of Services.
Services are just instances of classes that are supposed to provide some functionality like logging or authenticating users.
Some of core services in Prism are:

• IModuleCatalog
• ILoggerFacade
• IServiceLocator

Creating Services
Lets look at Emotwittion as an example, it uses two custom services:

• IGeoLocationService – to get longitude and latitude of a place in a world
• ITwitterMonitorService – to get status updates from Twitter

There are two places where we would typically register our custom services: in Bootstrapper or in Module Initialization method.
Most of the times we want only one instance of our service to exist, and this is easy to accomplish using Unity Container:

   1: Container.RegisterInstance<IGeoLocationService>(new GeoLocationService());

If we need several instances of a service, we can use overloaded method and name our instance:

   1: Container.RegisterInstance<IGeoLocationService>("GeoLocationServiceOne", new GeoLocationService());   

   2: Container.RegisterInstance<IGeoLocationService>("GeoLocationServiceTwo", new OtherGeoLocationService())

We can later get the desired instance of a service using Service Locator or Dependency Injection (described in more details here):

   1: ServiceLocator.Current.GetInstance<IGeoLocationService>("GeoLocationServiceTwo");

Async vs. Sync

It is very tempting to create synchronous services (because is much easier and straightforward), but if we really want to share services between Wpf and Silverlight we should use Asynchronous model, not only because it’s more efficient, but also because we may be forced to do so if service we try to develop calls WebServices (which are accessible in Async way only in SL).

I’d suggest following these rules:

Each asynchronous method should have Async in a name and event fired on completition with a name following <methodname>Completed pattern:

   1: public event EventHandler<Mokosh.Core.AsyncCompletedEventArgs<Location>> GetLocationByLocationNameCompleted;   

   2:      

   3: public void GetLocationByLocationNameAsync(string locationName, object userState);

As we can see above, GetLocationByLocationNameAsync method expects userState parameter which can be used by caller to identify a call (task Id) or store some context information to be retrieved when handling GetLocationByLocationNameCompleted event.

Closer look at the AsyncOperationEventArgs<T> will reveal that it contains property named Error of type System.Exception (same as System.ComponentModel.AsyncCompletedEventArgs class). This can be used by caller to get error information if something goes wrong.

Cross-Modules communication using Shared Services

We discussed how modules can communicate using EventAggregator before.

Another method of cross-module communication is through shared services.

We can use Inversion of Control pattern to obtain global (shared) instance of a service and use it to share data and pass messages between modules.

Playground

You can download Emotwittion Solution here here.

• Previous Entry: Prism 2: WPF and Silverlight – Events
• Next Entry: Silverlight 3 – Out-of-Browser (OOB) applications