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 Overview
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.
1: [Export] 2: public partial class MainPage : UserControl 3: { 4: }We can also export a class through its interface.
1: [Export(typeof(IBooksDataServiceProvider))] 2: public class BooksDataServiceProvider: DataServiceProvider , IBooksDataServiceProvider 3: { 4: }In order to import an object of a given type into a property/field, we use the import attribute.
1: public partial class App : Application 2: { 3: [Import] 4: public MainPage MainView 5: { 6: get { return RootVisual as MainPage; } 7: set { RootVisual = value; } 8: } 9: }We can also use the ImportingConstructor attribute to specify that all the parameters of a given constructor should be treated as imports.
1: public class BooksViewModel : ViewModelBase 2: { 3: [ImportingConstructor] 4: public BooksViewModel(IBooksDataServiceProvider booksProvider) 5: { 6: }In order to instruct MEF container to initiate the process of locating required exports and populating imports, we call CompositionInitializer.SatisfyImports(..)
1: public partial class App : Application 2: { 3: private void Application_Startup(object sender, StartupEventArgs e) 4: { 5: CompositionInitializer.SatisfyImports(this); 6: } 7: }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.
Dependency Injection
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 Application
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
In the previous post we used the DalSevice singleton class as a Dependency Lookup in order to allow replacing the data access layer with a Test Double when required.
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
1: [Export] 2: public partial class BooksPage : Page 3: { 4: [ImportingConstructor] 5: public BooksPage(BooksViewModel viewModel) 6: { 7: InitializeComponent(); 8: 9: DataContext = viewModel; 10: } 11: }The BooksPage is exported through MEF to its host (the main page), and injected with BooksViewModel on construction (notice the ImportingConstructor attribute).
The ViewModel
1: [Export] 2: public class BooksViewModel : ViewModelBase 3: { 4: [ImportingConstructor] 5: public BooksViewModel(IBooksDataServiceProvider booksProvider) 6: { 7: ... 8: 9: UsersCommand = new DelegateCommand<object>(o1 =>
10: { 11: var window = UsersWindow.Value; 12: window.Show(); 13: }); 14: } 15: 16: [Import]17: public Lazy<UsersWindow> UsersWindow { get; set; }
18: 19: public ICommand UsersCommand { get; private set; } 20: } 21: 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)
The BooksDataProvider
1: [Export(typeof(IBooksDataServiceProvider))] 2: public class BooksDataServiceProvider: DataServiceProvider , IBooksDataServiceProvider 3: { 4: private readonly BookStore m_bookStore; 5: 6: [ImportingConstructor] 7: public BooksDataServiceProvider(IDalConfiguration configuration) 8: { 9: m_bookStore = new BookStore(configuration.BooksDataServiceRoot); 10: } 11: }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
1: [Export(typeof(IDalConfiguration))] 2: public class DalConfiguration : IDalConfiguration 3: { 4: public DalConfiguration() 5: { 6: BooksDataServiceRoot = new Uri("http://localhost:16081/BookStoreDataService.svc"); 7: UsersDataServiceRoot = new Uri("http://localhost:16081/UsersDataService.svc"); 8: 9: } 10: 11: public Uri BooksDataServiceRoot { get; set; } 12: public Uri UsersDataServiceRoot { get; set; } 13: 14: }The DalConfiguration class defines the URIs of the available providers. It’s exported through interface to provide support for changing the data services URI.
Unit Tests
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.
1: var providerFake = new BooksDataServiceProviderFake(); 2: 3: var booksViewModel = new BooksViewModel(providerFake);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
1: var dataServiceMockUri = 2: new Uri("http://localhost:21978/BookStoreDataServiceMock.svc"); 3: 4: var configuration = 5: new DalConfigurationFake { BooksDataServiceRoot = dataServiceMockUri }; 6: 7: var provider = new BooksDataServiceProvider(configuration); 8: 9: BooksViewModel viewModel = new BooksViewModel(provider);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.
1: var productCatalog = new AssemblyCatalog(...); 2: 3: // Wrap the product catalog with CatalogExportProvider to enable overriding dependencies 4: var exportProvider = new CatalogExportProvider(productCatalog); 5: 6: var testCatalog = new TypeCatalog(typeof(BooksDataServiceProviderMock)); 7: 8: // Notice, the test catalog is placed before the product catalog, this instructs MEF container 9: // to choose test exports on top of product exports 10: CompositionContainer container = new CompositionContainer(testCatalog, exportProvider); 11: 12: exportProvider.SourceProvider = container; 13: CompositionHost.Initialize(container);The source code for the application and the unit tests can be downloaded from here
No comments:
Post a Comment