Design Smart Clients Based on cab and scsf (2) Translation

Smart Client software factory

Although cab provides us with a powerful platform, learning cab is definitely a challenge. To use cab, developers need to perform many steps manually. For example, they need to derive the Controller class, View class, model class from the basic class of workitem or implement case management. Scsf is an extension tool of vs2005 Professional edition. It provides many functions to automate the process of using the cab, and provides a wide range of detailed documentation to introduce how to use it, includes help and a set of Simulated Project implementation guides, such as the Global Bank Project Guide.

Scsf is based on guidance automation extension, a tool provided by Microsoft's pattern & Practices Team. Guidance automation extension helps architects and developers expand to automate typical development tasks to enhance and ensure that some instructions and guidelines are commonly used by the project. Scsf provides a wizard for the development of cab-based smart client programs and automation processes similar to creating models and case managers (except for event publishing and subscription.

Workitemcontroller: A class defined by scsf to complete the initialization process in workitem. When using scsf to create a workitem, we do not directly inherit from the basic class of the workitem, but inherit from the workitemcontroller to initialize the workitem.

Controllerworkitem: This is also defined by scsf. The workitem class initialized Based on workitemcontroller is controllerworkitem. It calls workitemcontroller for initialization.

Modulecontroller: The workitem Based on modulecontroller is the root of all workitems in the entire module. By default, scsf creates a module class derived from moduleinit, which automatically creates this root for the module.

Presenter: It is only responsible for the logic between one smartpart and the business model and is designed based on the MVP mode. MVP is a variant after the MVC mode is simplified. The biggest difference between MVC and MVP is that the view in MVP is fully controlled by presenter, while the controller and model in MVC can both control the view.

Development Process Introduction

As mentioned above, the development of cab-Based Smart Clients is case-centric. Therefore, it is critical to understand the client-based business. First, there are three aspects that affect the development process: shell, infrastructure services, and specific use cases. Therefore, to design a complex Smart Client, follow the following three principles:

1. First, you must have a deep understanding of the general requirements for most use cases. General functions related to the UI should be directly integrated into the shell, or at least the layout and design of the shell should be taken into account. General functions unrelated to the UI should be used as core services.

2. Create a specific use case diagram. In the design, use cases can be converted to workitem or sub-workitem. The interaction between use cases can be achieved through the command mode or the cab event proxy module. Logically closely related workitems. For example, they are implemented for the same actor and can be placed in a module.

3. Refine the use case diagram, analyze the relationship between use cases, reuse and security mechanisms. In the refinement process, you need to reconstruct the workitem slowly. A typical scenario is to find some workitems that originally belong to other modules, but are packaged into this module, or have nothing to do with their parent workitem. In fact, it is more suitable to put them in first-level workitems. First-level workitem has only one parent workitem and rootworkitem.

The first step of requirement analysis is completed by the core group. After requirement analysis, the Core Group begins to design shell and basic services. One of the key points is to find the core requirements for shell and basic services, which need to be converted into service interfaces.

Next, the second group should be the group that is most familiar with the business and start to analyze specific use cases. At the same time, the Core Group starts to develop shell and basic services. The development of Shell and basic services should be completed at the beginning. The rest of the work is workitem that meets all client-related business needs. Therefore, Shell and basic services should be completed at one time.

Because they are used by almost every workitem, you must complete shell and basic service development as much as possible before developing workitem in a larger scope. Further, when designing and developing a large number of workitems, it is necessary to develop a small number of workitems to verify whether the entire architecture is feasible. In the future, a small number of new requirements may be added to shell and basic services. This requires us to change the Service Interface (based on your own situation, it is also feasible to design a prototype before actual development, this is up to you ).

The case obtained in the specific case analysis is the basis for dividing workitem in cab development. Use Case-driven workitem design. Each use case is mapped to a workitem. The relationship between use cases displayed in the use case diagram shows which sub-workitems are used as well as the interaction between them through events or commands. Typically, studying and refining use cases and relationships can identify the relationship between use cases (parent, child, event, and command ). This research refinement affects how you organize workitems into modules. Therefore, you must analyze these cases carefully before developing them. The following sections will be detailed.

In short, the development of complex Smart Clients Based on cab adopts a hierarchical approach. Cab provides a basic framework, shell and basic service library are the basis of our applications (also a framework built on cab). The module in workitem is responsible for specific business applications and can be dynamically loaded into shell. Therefore, we can understand cab in two different ways: cab is a tool that can be used at any time and can be embedded into our smart client program; another is that you can build a similar framework structure based on cab to build an application framework suitable for your business and demonstrate this structure.

Shell and infrastructure service design

In the cab-Based Smart Client Program, the first part to be designed is shell. Shell is a specific client service that is responsible for loading and initializing basic Client Services. It loads and initializes modules, and provides the main application UI and a specific program for loading a level-1 workitem Smart Client. The UI of the main application is equal to each mounted module. Essentially, shell must meet the common requirements for all use cases. A typical shared interface element to be added to the shell is as follows:

Menu, toolbar, and status bar

Navigation controls, such as Outlook toolbar similar to outlook2003/2007

A general information display panel that displays information (such as errors and warnings) for users in its central location)

The task panel, which is in office2003/2007 or the taskbar, is the XP taskbar.

Quick tip panel, which provides a prompt for the user's current operation

These just tell you how to better integrate the shared interface elements into the shell. Through workspaces and uiextensionsites, cab provides a convenient mechanism to help you expand the interface in shell. Workspaces is used to completely replace the entire UI interface. uiextensionsites is used to extend a part of the existing UI interface, such as adding a toolbar or menu bar. As shown in.

Workspace and uiextensionsite are public to all services and loaded modules in the application. Cab allows you to obtain the information as follows:

Workitem. uiextensionsites ["sitename"]. Add <toolstripbutton> (newtoolstripbutton ());

Although this method gives you a lot of freedom, you may feel that developers use a "strong type" method to interact with shell. Further, this leads to tight coupling between various parts of the shell. Therefore, we recommend that you create a sandwich layer between the shell and the components to be added to the shell. Shell needs to provide some functions to other components. You can design an interface that is implemented by Shell (or presenter corresponding to the main form of shell, this expands the shell and uses the shell as the basic service used by other components of the cab. 4.

This is a simple but important idea, because the elements loaded to the Smart Client (the module contained in the workitem or basic service) do not need to know the names of the workspace and uiextensionsite. These elements can be used to obtain services as follows:

Ishellextensionserviceshellservice = workitem. Services. Get <ishellextensionservice> ();

Shellservice. addnavigationextension ("somenew menu", null, somecommand );

By implementing ishellextension, You can decouple shell's uidesign and basic services. As follows:

Public class shelllaoutviewpresenter: presenter <shelllayoutview>,

Ishellextensionservice

{

Public void addnavigationextension (...)

{

Toolstripbuttonnewbutton = new toolstripbutton ();

 

Workitem. uiextensionsites [uiextensionsitenames. outlooknavbar]

. Addingneweventargs

<Toolstripbutton> (newbutton );

}

 

Public void showinworkspace (...)

{

Workitem. workspaces [workspacenames. contextworkspace].

Show (smartpart, Info );

}

}

It is worth noting that this shell interface is exposed to other components to use only the UI-related functions in shell. It is also the entry point for extending the menu of other components loaded to the Smart Client, toolbar, taskbar on the left side of the window, or adding messages to the general information panel (see the previous article.

Compare workspace and uiextensionsite

As mentioned above, workspace completely replaces shell with the new UI. Typically, this step is implemented by the workitem in the application module. Uiextensionsite is a part of shell that can not be completely replaced, and it can be expanded by loading it to the Smart Client module. Typically, they can be used to start a workitem (use case); therefore, they are loaded in most cases through the moduleinit class.

More directly integrated into shell and encapsulated into separate modules

When common interface elements are involved, you often need to choose whether to integrate them directly into shell or encapsulate them into the basic modules of separation. The key factor is reusability. Do you need to use this universal UI elsewhere? Maybe you need to use it in other client shells? Or other modul needs to be displayed as part of the workitem interface? In this case, you should encapsulate it instead of integrate it directly.

The second factor affecting the selection is configuration and permissions. If you need to dynamically load or load based on permissions, You need to encapsulate the UI separately.

Encapsulate the shell layout separately or directly place it in the main shell application.

Of course, you can encapsulate the shell main form that contains the complete layout into a separate module. In fact, you will be asked this question when you use scsf to create a new project. But how do you choose? In fact, it is very simple: if you want to dynamically change the shell Layout Based on the permission or general configuration of the client, you must encapsulate it separately. If not, separate encapsulation is completely unnecessary.

Encapsulate the UI into a user control

You really want to know what you did when you put the UI directly in the shell or put the layout directly into the application without separately encapsulating it, because the demand is always changing, in addition, you often need to outsource these jobs to individual modules. In any case, at least for refactoring, you should encapsulate the complex parts of the UI into a separate user control and encapsulate the logic part into the presenter. Keep these models in mind that future reconstruction will not pay a higher price.