Windows Forms Controls

Digg This!

Page 1 of 2   next page »

The composite UI Application Block (called "CAB" in the online community) is a new application block that is being developed by Microsoft patterns & practices and is scheduled for release shortly after the final release of .NET 2.0. The current code for the Composite UI Application Block is the first Community Technology Preview. As with any beta release, there could always be changes before the final version. The core design and concepts, however, are less likely to undergo any major changes, and it is worth taking a look at the architecture and design of the block for several reasons:

• To see a "real-life" implementation of some interesting design patterns in accordance with Microsoft's own standards - patterns that could be useful in one's own work
• To evaluate the Application Block to determine if it (or portions of it) would be useful in an upcoming Windows Forms project
• To get a glimpse of some of Microsoft patterns & practices' guidance for using some of the new features of .NET 2.0

What is CAB?
CAB is an architectural framework that provides a flexible and decoupled approach for developing Windows Forms applications. It employs proven design patterns in a set of base classes and services that allow for construction of controls and forms and that can be used to control UI navigation, workflow, and application state. The CAB UI framework is designed to improve the development speed, ease of maintenance, reliability, and reusability in large Windows Forms applications.

In addition, CAB is built on a new component-based framework that is an extension of the System.ComponentModel namespace. This framework is based at its core on the Dependency Injection/Inversion of Control design pattern. This has the potential to give it immense flexibility and power; I will explore this later in this article. Along with the Dependency Injection implementation, CAB employs some of the new features of .NET 2.0, such as generics.

Background - Application Blocks and the Enterprise Library
The patterns & practices group at Microsoft provides guidance for the use of Microsoft technologies, as well as general software architecture and development patterns. Part of the way the patterns & practices group does this is to produce and distribute source code that has been developed using the best practices of Microsoft architecture. This code is distributed at no charge. The source code packages that are not full reference implementations are called application blocks.

The first application blocks came out several years ago and were released individually. They provided a great reference for developers, giving them a view into the best practices of Microsoft-produced source code and application architecture. Some of them provided a set of core components that could be used in almost any type of application to simplify common tasks such as database access, exception handling, logging, and encryption. Others provided design and architectural guidance to address complex design problems using established design patterns.

Since the first set of Application Blocks were developed one at a time and by separate teams, they had different core patterns, organization, and naming standards and were developed with different architectural approaches from one another. To provide a consistent approach, Microsoft released the "Enterprise Library" in late 2004 - this is a set of the most widely employed Application Blocks, re-engineered using consistent coding standards, patterns and architecture, and using the Configuration Application Block to handle reading and writing of all configuration settings.

The User Interface Process Application Block and the Composite UI Application Block (CAB)
One of the original Application Blocks that was not included in the Enterprise Library was the "User Interface Process Application Block." As those of you who used or read about this block know, the architectural concepts around which it was designed were solid, but the implementation worked better in some applications than in others. It made an attempt to abstract all User Interfaces and to control Web and Windows Forms navigation using the same approach, and the consensus seemed to be that it was better suited for Windows applications, primarily due to the greater control that Windows Forms give the developer over state when navigating backwards.

The Composite UI Application Block takes up the same goals as the User Interface Process Application Block, and this time is geared specifically for Windows Forms applications in .NET 2.0 (there will be a separate Application Block for ASP.NET Composite UI). It is the first application block that is being designed exclusively for .NET 2.0, and it is the first one to be rolled out since the introduction of the Enterprise Library.

Why isn't CAB in the Enterprise Library?
The Enterprise Library application blocks are basically sets of service provider classes. These classes provide simple interfaces for developers to access common, shared services to perform tasks such as checking security, connecting to and running commands against a database, logging, and loading/saving configuration information. The providers are all simple and straightforward to use. They support complex configuration options and flexibility in how they do their work, and they are designed to allow developers to easily add custom providers.

What the Enterprise Library does NOT provide is an overall architectural approach. The Enterprise Library Application Blocks are self-contained, and they can be integrated into virtually any architecture due to their flexibility. The User Interface Process Application Block and CAB, on the other hand, are architectures, at least for the User Interface layer of an application. They really drive how the User Interface works at a fundamental level.

For example, part of the package released with CAB defines a set of base container classes. In an application built using CAB, all objects that participate in the UI are created and exist inside these containers. Other CAB-defined classes control the layout of the interface. Controllers that are defined in the CAB architecture manage user workflow, and CAB handles storage and retrieval of state between views.

Basic Concepts - CAB and Component Model
The CAB core, as of the first Community Technology Preview, consists of three projects. The first two, CompositeUI and CompositeUI.WinForms, compose the UI-centric portion of the code. The third, ComponentModel, contains the structural classes that make up the backbone of the architecture.

Composite UI - Modeling the Use Case
One of the central concepts in CAB is the WorkItem. Each WorkItem represents a single use case. A WorkItem object is a container that holds all of the objects required to complete the use case for which it is responsible. These objects could be user controls (called "SmartParts" in CAB), state containers, or even other WorkItems to handle child processes.

SmartParts are the windows controls that you use to build the UI for an application. They are "smart" because they live within the context of a WorkItem and are self-describing. These can be any type of control, including custom-developed user controls. All you have to do to make a control a SmartPart is to mark the class with the [SmartPart] attribute.

Page 1 of 2   next page »