MSDN Magazine - September 2008 - (Page 74)

if needed. Finally, CreateShell is overridden with the specific logic to create the shell. In this case the code is implementing the Model View Presenter pattern, so the shell has an associated presenter. The bootstrapper shown in Figure 4 illustrates a common pattern when building a CAL app from scratch, which is to create an application-specific bootstrapper. A major benefit to this approach is that an application-specific bootstrapper enhances the testability of your application. The bootstrapper does not have any dependencies on WPF other than DependencyObject. You can, for example, create a test bootstrapper that inherits from the app-specific bootstrapper and overrides the CreateContainer method to return an AutoMocking container, thus mocking out all of your services. Additionally, because the bootstrapper provides a single point of entry for initializing composition and because the CAL does not rely on inheritance from framework classes in your application, you can integrate CAL into your existing applications with less friction than in previous frameworks. Note that the CAL itself does not depend on the bootstrapper at all, so you can refrain from using it if a bootstrapper does not fit your needs. In the CAL, a module is a class that implements the IModule interface. This interface has only one method, called Initialize. If the bootstrapper is equivalent to the application’s Main method, then the Initialize method is the Main for each module. For example, here you can see the Initialize method for WatchModule: public void Initialize() { RegisterViewsAndServices(); IWatchListPresentationModel watchListPresentationModel = _container.Resolve (); _regionManager.Regions["WatchRegion"].Add(watchListPresentationModel.View); IAddWatchPresenter addWatchPresenter = _container.Resolve (); _regionManager.Regions["MainToolbarRegion"].Add(addWatchPresenter.View); } Modules and Services As I mentioned earlier, in a composite application built using the CAL, the bulk of the application logic lives in the modules. The Stock Trader reference implementation includes four modules: • NewsModule provides related news feeds for each fund that is selected. • MarketModule provides trend data, as well as real-time market data, for the selected fund. • WatchModule provides a Watch List that displays a list of funds you are monitoring. • PositionModule displays the list of funds in which you have invested and allows you to perform buy/sell transactions. Figure 4 Stock Trader Bootstrapper public class StockTraderRIBootstrapper : UnityBootstrapper { private readonly EntLibLoggerAdapter _logger = new EntLibLoggerAdapter(); protected override IModuleEnumerator GetModuleEnumerator() { return new StaticModuleEnumerator() .AddModule(typeof(NewsModule)) .AddModule(typeof(MarketModule)) .AddModule(typeof(WatchModule), "MarketModule") .AddModule(typeof(PositionModule), "MarketModule", "NewsModule"); } protected override ILoggerFacade LoggerFacade { get { return _logger; } } protected override void ConfigureContainer() { Container.RegisterType (); } base.ConfigureContainer(); Before getting into the module specifics, two things that are worth discussing here are the references to _container and _regionManager. If the interface doesn’t have these defined, then where do they come from? Am I hardcoding logic within the module to go find these dependencies? Fortunately, the answer to that last question is no. This is where having an IoC container comes to the rescue. When a module is loaded, it is resolved from the container, which also injects any specified dependencies into the module’s constructor: public WatchModule(IUnityContainer container, IRegionManager regionManager) { _container = container; _regionManager = regionManager; } Here you can see that the container itself is injected into the module. This is possible because the bootstrapper registers the container in its ConfigureContainer method: Container.RegisterInstance (Container); Giving modules direct access to the container allows the module to register and resolve dependencies from the container in an imperative fashion. You don’t need to have this imperative registration. Instead, you can put all services into a global configuration. Doing this would mean that all services must be registered when the container is initially created. However, most modules have module-specific services. And by keeping the registration in the module, those module-specific services are only registered if the module is loaded. In the case of the module you were shown earlier, the first call is to RegisterViewsAndServices. In this method, each of the specific views for WatchModule is registered in the container along with an interface: protected void RegisterViewsAndServices() { _container.RegisterType ( new ContainerControlledLifetimeManager()); _container.RegisterType (); _container.RegisterType (); _container.RegisterType (); _container.RegisterType (); } } protected override DependencyObject CreateShell() { ShellPresenter presenter = Container.Resolve (); IShellView view = presenter.View; view.ShowView(); return view as DependencyObject; } Requiring that the interface is specified fosters separation of concerns and allows other modules in the system to interact with the view without requiring a direct reference. Putting everything in the container allows each of the dependencies for the different objects to be injected automatically. WatchListView, for example, Composite WPF 74 msdn magazine

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.