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

Introduction

So far in this series of articles the focus has been on the core functionality of the Composite Application Block (CAB). No mention has been made of the Smart Client Software Factory (SCSF), in spite of the fact that the series is entitled ‘An Introduction to the Composite Application Block and the Smart Client Software Factory’.

This article and the ones that follow will remedy that. They will discuss what the Smart Client Software Factory is, how it relates to the Composite Application Block, and how to use it.

Versions of the Composite Application Block and Smart Client Software Factory

The first version of the Composite Application Block was released in December 2005. This had all of the features that have been described in this series of articles so far. As was mentioned in part 1 of this series, the Composite Application Block on its own is quite difficult to understand and learn how to use. Furthermore, documentation and support in the initial version were somewhat lacking: many developers complained that they couldn’t understand how to use the new framework.

The Patterns and Practices team released a follow-up version in June 2006, and another in May 2007. However, they did not attempt to change the core Composite Application Block code. Instead they provided additional documentation and examples, as well as a way of automatically generating code for various useful patterns using the Composite Application Block. We’ll examine this in a little more detail below.

The idea behind these SCSF releases was to make it easier for developers both to learn and to use the Composite Application Block software (and other application blocks). However, as we shall see, the SCSF introduces new code and patterns on top of the CAB’s already complex structures, and the documentation could still be clearer. In many ways the Patterns and Practices team have added to the confusion with these releases rather than clarifying the situation.

Software Factories

The last two releases were branded as the ‘Smart Client Software Factory’. A ‘software factory’ is one of the latest computer industry buzzwords.

The idea behind software factories is that current software development practices depend on highly-skilled developers, who are similar to craftsmen in a pre-industrial age. The argument is that the need for highly-skilled craftsmen is the reason that many software projects fail: there are too few really good craftsmen, and they are usually hand-crafting from scratch in every new project. We need to ‘industrialize’ the software development process. Software should be created using ‘software factories’.

Like many computer industry buzzwords, what a ‘software factory’ is in practice is a little unclear. It tends to vary depending on the author, but in general a software factory should provide a means of producing code in a standard way. This may mean reusing and customizing existing code, simply following a set of guidance practices, or generating code automatically based on a model, which may be visual. It may mean a combination of all of these techniques. The phrase is also often used to describe model-driven development, possibly using domain-specific languages.

Smart Client Software Factory

Microsoft’s ‘software factory’ is slightly simpler than some of the usual definitions described above. The ‘Smart Client Software Factory’ comprises a small set of code generators plus some documentation and examples. The code generators are quite straightforward, producing code to set patterns (there’s no model to be maintained here).

The paragraph below is from the SCSF documentation:

‘The software factory provides a set of proven and integrated practices that are exposed through patterns, How-to topics, QuickStarts, a reference implementation, a Visual Studio Guidance Automation Toolkit package, and architecture documentation. The software factory guides projects through the development of smart client applications based on the architecture of the Composite User Interface Application Block.’

The Visual Studio Guidance Automation Toolkit Package

The Smart Client Software Factory includes a ‘Visual Studio Guidance Automation Toolkit Package’. This is an add-in to Visual Studio that automates certain software development tasks relating to the CAB. Some of these are added to the right-click context menu in Solution Explorer.

Probably the most useful Guidance Package, however, is the one that generates a new Smart Client Application project. This is also a good place to start when investigating what the Smart Client Software Factory can do.

This Guidance Package is available if you request a new project in the usual way inside Visual Studio after the SCSF has been installed. The New Project window has a project type of ‘Guidance Package’ available. Underneath that you can choose a new ‘Smart Client Application (C#)’:

If you select this option the Guidance Package will show a screen that allows you to set some properties of your solution. In particular you need to tell the Package where the Composite Application Block libaries are, and to set some options. These include whether you want a separate module for layout of the Shell (in general you won’t want this). The Guidance Package will then set up a Smart Client solution as below:

The SmartClientDevelopmentSolution

This is a base solution for a smart client project using the Composite Application Block. It gives your code some basic structure. It also gives you a lot of code on top of the Composite Application Block code itself: the various projects contain about 3,000 lines of code in total.

So we have even more code to try to understand if we are to use the resulting project effectively.

As you can see we are given four basic projects:

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.

Part 19 of this series will discuss this solution a little more, and will look at SCSF Business Modules.

References

Discussion of software factories:
http://www.methodsandtools.com/archive/archive.php?id=64