CAL Cookbook Part2

Now that we’ve built a CAL application you might ask, ‘What does it do for me?’ Certainly from what we did in the previous article there isn’t an obvious answer. One of the benefits of CAL is its facilities for building modular applications. But you can certainly build modular applications without CAL. Using separated presentation patterns you can facilitate parallel development as well as independent testing. So those are not motivators in and of themselves for using CAL. Likewise you can implement a logging service as well as a publisher/subscriber service for use with your applications. Even the dependency resolution facilities are not unique to CAL since they are provided by the adjunct Unity container. As the name indicates, CAL is a library, so it provides all of the above facilities within one framework. This gives you uniformity within your applications, not to mention that you didn’t have to write or test any of the code!

 ‘OK, so I’m getting a lot of stuff for free. But if I don’t need it…’ and that’s the question that you need to answer. Which of course can only be answered from your specific application requirements. Essentially that’s the focus of these articles, to analyze the library in sufficient detail to be able to evaluate the benefit of each facility. Here is a set of questions to use as a guide.

•  Does the UI composition, using named regions, provide any benefit to your application?
• Is dynamic configuration (or extensibility) of the application important?
• Does dependency injection reduce the complexity of the application?
• Do you need application logging facilities?
• Do you need event driven inter-module communication?
• Does the application benefit from multi-targeting?

You can ponder those questions as we discuss the various facilities provided by CAL. Hopefully by the end, the answers will be clear.

In the previous article we described how to build a CAL application but it was simply a shell (yes, it’s intentional). We’ll return later to describing the Unity container and the facilities it provides but for now let’s add a module so that we can start to see how the whole application is put together. The first question to answer is just what is a module. From CAL’s perspective a module is a compiled chunk of code, anything really. A module is built as a class library project and the only requirement on it is that it contain a class that implements the IModule interface. And IModule defines just one method, Initialize(). Initialize is where you  give your module its identity, that’s where initializations and identifications take place.

Even though a module can be anything, it is usually a set of logically related classes. In this way the module provides a cohesive service to other parts of the application.  A CAL module is also normally composed as a layered design, containing the presentation, business and data access layers within the module.

Let’s continue by adding a module to the base application we defined previously. I’ve re-named the application as WidgeNet2,  in order to make comparisons to the automation application presented here and I’m also going to re-use some of that code. CAL applications are usually complex applications with many projects making up the solution. So it’s a good idea to create sub-folders in your solution in order to keep things somewhat organized. To the sample code solution I’ve added two folders and created a class library project in each one as shown below.

Since there are always ‘common’ definitions that will be required across multiple modules I’ve set up a common library to contain those definitions. Your specific project will dictate the best way to organize your files. In the modules folder I’ve created a class library project and called it Weebit. As I mentioned previously I’ll be making comparisons and using code from the original WidgeNet article.

CAL provides various mechanisms to define or specify the modules that comprise an application. You can specify your modules in code, or you can place all your modules in a folder and have CAL load them automatically, or you can specify the modules in the config file. You can also choose to combine any of the previous methods. For example there may be some modules that will always be part of the application and you can specify those in code while other modules could be defined through either of the other mechanisms. We’re going to use the config file for the sample code project.  The following shows how modules are specified.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="modules" type="Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite"/>
  </configSections>
  <modules>
    <module assemblyFile="Modules/WidgeNet2.Weebit.dll"
            moduleType="WidgeNet2.Weebit.Weebit, WidgeNet2.Weebit"
            moduleName="Weebit"/>
  </modules>
</configuration>

If you recall, in the previous article we provided an override for GetModuleCatalog() in the Bootstrapper class. And there, we created an instance of ConfigurationModuleCatalog. That’s the class that knows how to identify and load the modules we’ve defined in the config file. You would use DirectoryModuleCatalog if you wanted to specify modules by simply storing them in a specific directory folder. To specify modules in code you would use the AddModule() method of the ModuleCatalog class.

Previously I indicated that a module only needs to implement IModule and that IModule has only one method, Initialize(). So we need to start defining what the Weebit module is in order to be able to initialize it. In the original WidgeNet article, Weebit was a WCF data service so we’ll make use of that code. Since I know I’ll be adding a presentation to the module I’m adding three folders to the project as shown below and I’ve created a WeebitDataSvc class that implements IWeebitDataSvc interface.

Since there will be other modules that will require the interface and data objects definitions, they are defined in the Common class library.

Now we are ready to start defining our module. At this point all that the module contains is a data service but that’s enough to show the mechanics. The following shows the Weebit class that implements IModule interface

    public class Weebit : IModule
    {
        private readonly IUnityContainer container;

        public Weebit(IUnityContainer container)
        {
            this.container = container;
        }
        public void Initialize()
        {
            container.RegisterType<IWeebitDataSvc, WeebitDataSvc>(new ContainerControlledLifetimeManager());
        }
   }

We’ll discuss the container in detail in a subsequent article. For now just know that it provides several facilities, two of which are shown above. In the Initialize() method we tell the container what types we’ve defined. Since the type that we are registering here is a service we would like it to be a singleton. The container can also manage the lifetime of our types so we don’t have to mess with instantiating and managing it. Later when we add other types to our module we’ll be revising the Initialize method to register those types.

Compile and run the sample code project and add a breakpoint in the Initialize method and another in the constructor for WeebitDataSvc. You’ll notice that the Initialize method gets called but the WeebitDataSvc is not instantiated. That’s because there is nothing in our application so far that makes any reference to the service so the container has no need to instantiate it. If you modify the Initialize method as follows and re-run the application you’ll see that the service is indeed created.

        public void Initialize()
        {
            container.RegisterType<IWeebitDataSvc, WeebitDataSvc>(new ContainerControlledLifetimeManager());
            IWeebitDataSvc temp = container.Resolve();
        }

So what does this registration do for us? It solves our dependencies problem that we described in a previous article. The factory that we were looking for is part of what the Unity container provides. This facility is dependency injection. What we are doing above by registering our types is telling the container about our types so others can make use of them. The container will then manage the instantiation and passing a reference to our types to any other module that needs them. In a later article we’ll create the Weeble module. That module will have an object that will need to have access to WeebitDataSvc. Simply by specifying the interface, IWeebitDataSvc, in the constructor the container will then take care of making sure that WeebitDataSvc exists and passing a valid interface reference in the constructor.

In the next article we’ll continue by adding a presentation layer to our module.