Let us talk about a real world example for a moment.
Say you are a vertical selling corporation of some kind, meaning that you sell to companies that do similar things. For example you might be selling to retail stores and your application will show their products. One of the problems is that your application will need to integrate with their CMS (Content Management System) to get product data. In Silverlight 3 your customers might need to provide a WCF Service to talk too. That WCF service they then provide has to have a certain API Signature or worse still they might need your code and need to recompile or YOU have to recompile for each customer or some other hack to make the application work.
Using MEF your customer still will need to get the data somewhere but it makes it easier on them to do this without mucking with your code. To make it work a customer can drop a 'XAP' that provides the content and your application doesn't care about WCF API signatures or other requirements that make it difficult to wire it into the existing system. Your customers can now easily extend, change or filter what and how their data gets to the application you built for their vertical.
In many ways this is like making the model of your application (speaking in the MVVM since) 'open source' and not only pulls the model out of the rest of the application into just about anything else and lets that model be manipulated by the client without rebuilding the application in any way.
Getting Started With MEF?
MEF is pretty straight forward to get started using since it is part of the Silverlight framework in these name spaces and you need to make sure you reference them at the project level.
System.ComponentModel.Composition
System.ComponentModel.Composition.Initialization
Now that we have the bits available, using MEF is as easy as Importing, Exporting and maybe a little code. The main idea is to be able to code or property decorations to allow MEF to find elements either being exported or imported and tie them together. We can look at this process as being able to export the data, import the data and composing the data in an abstract way that allows the elements of this process to be abstracted from our application to a degree that it can be done externally to the application post compile. "Gah!," you say? Let's take a look at the next section and learn more about this process?
MEF'd Properties in and out of our Application
Here we will work out the basics of using MEF in our application. We can start simple by creating some properties and decorate them so that we can build out our application and have them magically set by MEF. Ok maybe it is not magic so let's focus on the properties that will be set first and see how it is done. Take a look at the following code sample:
[Import("SomeValue")]
public string SomeValue;
You can see here we have 2 lines of code. The second line is our traditional string property of some object like a string. The declaration line before it is what exposes our property to MEF and allows MEF to set it. You'll note that we use a magic string here. I know this is generally not well thought of by your standard architecture astronaut but you need to have a key value in the form of a magic string to have MEF do the data mapping unless you want to define your own import attributes which we will talk about later on. Next we can take a look at the code that sets this value.
CompositionInitializer.SatisfyImports(this);
You can see here that we are doing this programmatically and we get our data from the MEF catalog. By doing this in the constructor we allow MEF to go get our data where it is coming from and loading it and we can then use it as needed in our view. This MEF process is much like dependency injection might be used in a MVVM View. Really making this work then requires that we also have this object we are talking about in our constructor. To make this week we still need to have a simple class that exports that data in such a way as we can have some data. The following code does that.
[Export("SomeValue")]
public string SomeValue = "foobar";
Notice the export declaration in this sample. When this current assembly is running we get this data element automatically added to the catalog. Going back to the sample that included the catalog you can see that we created an instance and added the current application running as our package. Once we have added a package to our catalog we can then create a container that using the container we can then ask MEF to match the elements together to do our 'binding' So how then do we make this a two way street or deal with larger collections?
Making our Properties a 2 way Street
A popular construct in Silverlight and in the XAML world altogether is the ObservableCollection. ObservableCollections allow us to do lots of things but let us focus on the fact that it is a bindable collection of data that we want to be populated by MEF. Now take a look at the following lines that show a declaration and a collection property of come class.
[Export("SomeStuffs")]
public string Stuff1 = "blah1, blah";
[Export("SomeStuffs")]
public string Stuff2 = "blah2, blah";
[ImportMany("SomeStuffs", AllowRecomposition = true)]
public ObservableCollection
As you can see this looks mostly like the first property we looked at earlier but here we are creating an observablecollection. The ImportMany declaration above it he collection allows the multiple element collection to come through and by also setting 'AllowRecomposition' the property can then be set over and over again by MEF. From this standpoint point we are ready to really build something separate from our application.
Exporting a Class in a Separate Xap
To create a Xap we can use a standard Silverlight project that we add to our solution. Since we are going to load the xap we can get rid of the classes (x and y). Create a class called z and make it look like this code:
public class SomeClass
{
[Export("SomeValue")]
public string SomeValue = "foobar3";
}
In this class you can see we create a class with 4 properties and use export to the same key name. This creates the effect of the values being exported to the MEF catalog as a collection that will get associated with the collection we created in the last section. For this to work we need to make sure that our Xap is referenced in our first app.
Downloading Xap Dynamically
Now that we have our collection and a new xap with a class that exports values we want we can look at importing the Xap and using MEF to wire that up to the data we need. Take a look at the following code:
[Import("SomeValue", AllowRecomposition=true)]
public string SomeValue;
DeploymentCatalog catalog = new DeploymentCatalog("MEFModel.xap");
// in constructor:
CompositionInitializer.SatisfyImports(this);
catalog.DownloadCompleted += new EventHandler
catalog.DownloadAsync();
void catalog_DownloadCompleted(object sender, System.ComponentModel.AsyncCompletedEventArgs e)
{
// some code...
}
This code can be added to the constructor of our application just after the call to AddPackage. You can see that we pass a Relative URI to our other Xap and that we add it to the package when it loads. This can also be an event handler to to the load. In this case we get the content added to the package and it gets wired up based on the name key values that we have set by the ImportMany and Export declarations. Now the cool thing is that we don't need to keep this in the constructor. We can call this same 'DownloadPackageAsync' from any event handler or other block of code that we need. We could use this to load content dynamically pending on certain conditions such as localization.
This is all wonderful but there is one problem with using a separate Xap that has the MEF bits in it. This means that both Xaps have MEF and now ours Xaps are twice blotted from MEF using more memory then needed. Fortunately there is way around this is to set the additional Xaps to use include this in the build. In Visual Studio in the other projects find the Library reference to the MEF and right click and select properties. On the reference property pain there is a property called 'Copy Local' and we need to set this to false. This way only one copy of the MEF bits will be in the overall application saving Xap size by not blotting all the Xaps with the same bits.
