I was with a client recently and we were looking at refactoring some of their system to use Prism. This client had created a lot of infrastructure to do what Prism does (before Prism was released for Silverlight) that they wanted to opt into using Prism instead.
Out of the box Prism works well for composing your applications, but for particular cases it may not be perfect. In this case the client wanted to be able to process the .xap file before it was passed onto to the module loader. So looking through Prism's Modularity code and found that IModuleManager interface. In order to provide my own implementation I wrote a simple implementation of the interface:
public class CustomModuleManager : ModuleManager
{
IEnumerable<IModuleTypeLoader> typeLoaders;
public CustomModuleManager(IModuleInitializer moduleInitializer,
IModuleCatalog moduleCatalog,
ILoggerFacade loggerFacade)
: base(moduleInitializer, moduleCatalog, loggerFacade)
{
}
// Replace the module loader with our own
public override IEnumerable<IModuleTypeLoader> ModuleTypeLoaders
{
get
{
if (this.typeLoaders == null)
{
this.typeLoaders = new List<IModuleTypeLoader>()
{
new CustomXapModuleTypeLoader()
};
}
return this.typeLoaders;
}
set
{
this.typeLoaders = value;
}
}
}
This module manager is mostly used so I can get at the module loader list. In this case I just returned a list containing my own custom XapModuleTypeLoader as shown above. My custom module loader looks like this:
public class CustomXapModuleTypeLoader : XapModuleTypeLoader
{
protected override IFileDownloader CreateDownloader()
{
return new CustomFileLoader();
}
}
The thin implementation of the ModuleTypeLoader is to simply inherit from the existing XapModuleTypeLoader class and just override the CreateDownloader to return a custom downloader. The custom downloader is key as that is what downloads and returns the Stream that contains the actual .xap file. By writing my own, I can intercept the .xap file before it gets returned. Here is the CustomFileLoader:
public class CustomFileDownloader : IFileDownloader
{
FileDownloader dler = new FileDownloader();
public CustomFileDownloader()
{
dler.DownloadCompleted +=
new EventHandler<DownloadCompletedEventArgs>(dler_DownloadCompleted);
}
void dler_DownloadCompleted(object sender, DownloadCompletedEventArgs e)
{
// Remove the event handler (so we don't leak)
dler.DownloadCompleted -= dler_DownloadCompleted;
// If someone cares, decrypt the stream and throw the event
if (DownloadCompleted != null)
{
if (e.Cancelled || e.Error != null)
{
DownloadCompleted(this, e);
}
else
{
// Before you return the resulting stream,
// make any changes you need
DownloadCompleted(this,
new DownloadCompletedEventArgs(e.Result,
e.Error,
e.Cancelled,
e.UserState));
}
}
}
#region IFileDownloader Members
public void DownloadAsync(Uri uri, object userToken)
{
dler.DownloadAsync(uri, userToken);
}
public event EventHandler<DownloadCompletedEventArgs> DownloadCompleted;
#endregion
}
The downloader is pretty simple in that it uses a FileDownloader to do the downloading and just provides a place where we can intercept the download before it returns stream.
All this code was essential written to allow us to replace the default implementation of the IModuleManager. But how do we use the new IModuleManager? Since Prism uses Unity for Dependency Injection, I realized I could just register my type with the container and it would be used:
public class Bootstrapper : UnityBootstrapper
{
// ...
protected override void ConfigureContainer()
{
Container.RegisterType<IModuleManager, CustomModuleManager>();
base.ConfigureContainer();
}
}
By simply registering the IModuleManager with the CustomModuleManager, Prism gets injected with my implementation of the interface. Elegant.
This holds true for many parts of Prism. If you need to replace some implementation of the Prism framework, before you start modifying the source code, make sure you can't just implement the interface and use the container to inject it into the system.
You can get the source at:
http://wildermuth.com/downloads/CustomModularity.zip
I had a chance to sit down (metaphorically) with Dmitry Lyalin and Peter Laudati and talk about Silvelright, MVVM and Prism 2.0. Let me know if you agree, disagree or think that I am a little obsessed with IoC containers.
The Connected Show is a podcast on New Microsoft Technology for the developer community, produced independently by Dmitry Lyalin and Peter Laudati.
Erik Mork, Silverlight MVP, host of the SparkingClient Podcast and an instructor for The Silverlight Tour, has compiled a new set of Prism for Silverlight Resources. He recently completed a number of podcasts and videos on how to use Prism in Silverlight. This blog post enumerates the ten things every developer should know about Prism and links over to resources that explain each point. If you're new to Silverlight and have heard a lot about Prism and/or MVVM, this list is worth reading and following.
.jpg)
The new MSDN Magazine is out and my article on creating composite Silverlight applications using Prism is finally available. If you're building large scale Silverlight applications and need to learn how to compose pieces of your application together, go read the article!
I had the recent pleasure of sitting in when Erik Mork interviewed the PnP team responsible for Prism recently. We talked about building large applications, the purpose of parts of Prism and how Prism relates to the original Composite Application Block (CAB).
The first of these podcasts is now available:
http://www.sparklingclient.com/prism-in-silverlight/
