Introduction To The Smart Client Software Factory (CAB/SCSF Part 18)

1. Shell

This is the start-up project for the solution. It is very similar to the start-up projects in the sample applications we’ve already seen in this series of articles: it has a start-up class (ShellApplication) which (indirectly) inherits from FormShellApplication. It has a form, ShellForm, which is the containing window for the application. It has a ProfileCatalog which will contain the composite application modules to be loaded.

If you compare this the Naïve Application sample code from part 1 of this series of articles you will see the similarities.

However, there are subtle differences as well, mainly in the form of extra code constructs. For example, ShellApplication actually inherits from a class called ‘SmartClientApplication’ which in turn inherits from FormShellApplication. The SmartClientApplication class simply sets up some SCSF services.

Additionally the ProfileCatalog now allows us to specify dependencies. We also have a Constants folder with a series of class files in it. We’ll examine these extra code constructs in later articles.

2. Infrastructure.Interface

The remaining Infrastructure projects are intended to provide common functionality for all of the composite applications we add into our solution. However, we don’t want to directly reference the projects that contain the code. Instead we want to hide the code behind interfaces in a separate library and reference the interface library. Infrastructure.Interface is this interface library. It mainly contains interfaces, with some simple classes.

3. Infrastructure.Library

The Infrastructure.Library project contains the bulk of the new code that this SCSF solution gives us. In fact it contains about 2000 lines of code, including such things as the Action Catalog, and support for loading modules using sources other than ProfileCatalog.xml.

4. Infrastructure.Module

Infrastructure.Module is an empty module project. It is intended that any code that we as developers want to add to the infrastructure section of our solution will go in here. It is a CAB module, which we have seen before, and it contains a ModuleInit class as we’d expect (see part 1 of this series of articles). However, it also contains a ModuleController class, which inherits WorkItemController. This will be discussed further in the next article.

Conclusion

This article has given us an overview of the Smart Client Software Factory, and shown how one of it’s key components is the ability to create a standard solution that can be used as the basis for a Composite Application Block application.

SCSF Business Modules: Start Up And The ControlledWorkItem (Introduction To CAB/SCSF Part 20)

        public override void Load()
        {
            base.Load();

            ControlledWorkItem<ModuleController> workItem = _rootWorkItem.WorkItems.AddNew<ControlledWorkItem<ModuleController>>();
            workItem.Controller.Run();
        }

ControlledWorkItem

ControlledWorkItem is a class that inherits directly from WorkItem. So a ControlledWorkItem is a WorkItem. The ControlledWorkItem also adds additional functionality to the WorkItem, and, crucially, it is a sealed class (which means we can’t inherit from it).

How ControlledWorkItem Addresses the Problem

ControlledWorkItem<ModuleController> workItem = _rootWorkItem.WorkItems.AddNew<ControlledWorkItem<ModuleController>>();

ModuleController

We can access the ModuleController instance from the ControlledWorkItem using the Controller property. We can then call a Run method on that class. This is the standard pattern that is generated by the Guidance Automation Package: note that the final line in the Load method above is:

workItem.Controller.Run();

So we can add start up code for the WorkItem into the ModuleController class in the Run routine.

The SCSF gives us a default ModuleController whenever we set up a Module, as we have seen. This has a default Run method. There isn’t any code that actually does anything in this method, but four empty methods are set up in ModuleController to indicate to us the sort of things we should be doing:

    public class ModuleController : WorkItemController
    {
        public override void Run()
        {
            AddServices();
            ExtendMenu();
            ExtendToolStrip();
            AddViews();
        }
    ｝

WorkItemController Class

Note also above that our default ModuleController inherits from a class called WorkItemController, which is an abstract base class intended to be used just of these controllers. Inheriting from this ensures that we have a Run method in our derived class as there is an abstract function of this name in the base class.

The base WorkItemController also gets a reference to the associated WorkItem using our usual dependency injection pattern. This can be accessed via the WorkItem property on the WorkItemController class.

Finally the WorkItemController class has two overloaded ShowViewInWorkspace methods, which can create and show a SmartPart in a named Workspace in the WorkItem.

Obviously we don’t have to make our ModuleController inherit from WorkItemController. However, if we don’t this base class functionality will not be available.