In the previous post we walked through the process of developing three tiers web app using Silverlight 4.0, MVVM and WCF Data services. In this post, we’ll see how we can take advantage of the new Managed Extensibility Framework (MEF) for Silverlight in order to loosen the coupling between the parts in the application and by that 1) simplify the development process, 2) make our application more extendable and 3) much more and testable.
MEF is specially important for Silverlight since it provides a way to reduce the app startup footprint and dramatically improve the user's startup experience by using the DeploymentCatalog (previously PackageCatalog) feature, which allows breaking the xap file into pieces, download the basic xap on initialization, and download the other xaps a-synchronously on demand or immediately after startup.
In the next post, we’ll develop a testing strategy for the demonstrated application, which includes component level and multi-component level tests.
MEF introduces a great way to integrate the dependency injection pattern into an application. It provides a standard way for a component to export any of its parts (classes) to other components, and to import external parts from any component in the xap boundaries.
In a typical application, when the host component starts, it instruct MEF to satisfy the imports tree of its root object, as a result, MEF make use of automatic exports discovery protocol in order to locate and instantiate the required objects and to wire them together in the correct order.
In order to export a class, we simply decorate it with the Export attribute.
We can also export a class through its interface.
In order to import an object of a given type into a property/field, we use the import attribute.
We can also use the ImportingConstructor attribute to specify that all the parameters of a given constructor should be treated as imports.
In order to instruct MEF container to initiate the process of locating required exports and populating imports, we call CompositionInitializer.SatisfyImports(..)
In the sample above, we instructed MEF to satisfy the imports of the App object, as a result, MEF searches all the assemblies in the xap in order to locate the classes that need to be imported and there dependencies. Which practically means that MEF search for MainPage, and if MainPage imports other classes in its implementation, MEF will import them as well.
The dependency injection (DI) design pattern is used to promote ‘Separation of concerns’, Modularity, Extensibility and Testability. It dictates that all the parts in the application will communicate with there dependencies though interfaces, and that every part will be injected with all of its dependencies, rejecting the use of static objects and Singletons in the application.
With DI, there’s always some kind of a ‘container’ that make sure that the parts are injected with there dependencies. When implementing the DI pattern without the use of a dedicated framework, the application instantiate the parts and wire them up together.
With MEF, we only have to declare that part A depends on part B (the dependency), and a framework ‘dependency injection container’ take care of instantiating Part B and injecting it to part A. This is particularly useful when part B is shared among multiple parts scattered around the application, in such case, we don’t have to keep track of part B instance and figure out how to distribute it to its consumers (for instance, by using the Singleton pattern), the framework take care of it for us.
The new MEF based application looks exactly like the application reviewed in the previous post, but with the addition of a new window that displays list of users (pulled out from the data storage using a dedicated data provider).
High Level Design
Since we’ve chosen to inject dependencies instead of hard wiring the parts and using Singletons - we no longer need a bridge between the presentation parts (ViewModels) and the data provides, so we can retire ourselves from the singleton DalService,
With MEF, every ViewModel simply declare the interface of the data provide/s that it depends on, and the ‘dependency injection container’ make sure that it’s injected with them.
Here’s the new design:
Now lets see some code!
Since we already reviewed the main components of the application in the previous post, we’ll focus on the code that was added to integrate MEF into the application.
The View Code Behind
The BooksPage is exported through MEF to its host (the main page), and injected with BooksViewModel on construction (notice the ImportingConstructor attribute).
The ViewModel is exported (for the favor of BooksPage) through MEF. It’s injected with the BooksDataServiceProvider on construction and with UsersWinodws on demand (notice the Lazy<T> paradigm)
Since the data provider need to be replaced with alternative implementations (for testing in our case), we export it through its interface. In addition, we need to be able to change its configuration so we added a new configuration class that is injected to the data provider on construction.
The DalConfiguration class defines the URIs of the available providers. It’s exported through interface to provide support for changing the data services URI.
During unit tests, in order to test the presentation logic in isolation we simply inject the ViewModel with a test double (usually fake) instead of the real data provider.
In order to test presentation logic against real data access layer, we can inject the ViewModel with a real data provider, and configure the data provider to target a fake/mock data service
Unit tests should not make use of MEF container for building dependencies. As presented above, a typical test starts with instantiating a ViewModel, instantiating its dependencies (here we can replace the dependencies with test doubles) and injecting the ViewModel with its dependencies. In integration tests, we run the entire application and let MEF container do its job, naturally, we’ll prefer to include the real parts rather than using test doubles.
However, in some cases we might want to use test doubles in integration test, to accomplish that we need to replace the default CompositionContainer, and use the CatalogExportProvider to allow ‘overriding dependencies’ and to instruct MEF to use our test doubles instead of product implementations.
The source code for the application and the unit tests can be downloaded from here