Design of Smart Clients Based on cab and scsf (I) Translation

Introduction

The original author of this article is racon software GmbH, which is a software workstation of raiffeisen banking group in ordid state. It provides architectural guidance for the design and implementation of complex Smart Clients, these smart clients are based on the cab and scsf provided by the Microsoft patterns & Practices Group.

The starting point of this article is to help racon software GmbH architects and major developers design and implement a new complex Smart Client for banking desktop. The idea behind this desktop application is that in daily business, bank staff often use many different client-based applications. At the beginning, the problem was discovered because every client had a different job. Every day, employees had a headache for switching back and forth in these different ways of work. Moreover, applications are not uniform, so many things need to be repeated multiple times in different applications. From the IT perspective, it is quite difficult to manage multiple applications, and the reuse of common functions is almost impossible. Therefore, racon
Software GmbH wants to create a general program as a platform for banking applications. Every bank program can be managed by this platform. These programs are eventually modularized and can be dynamically added to this platform. They can be loaded and initialized based on the user's security concerns. Therefore, users can only see the other parts allowed by the program. All different applications are embedded in a central module, and the common services they use are managed by platforms like a bank desktop, which makes it easier to manage multiple applications, common functions can also be reused. Since modules are dynamically configurable and different application components are loosely coupled and independent from each other, the most critical requirement is how to implement communication between these components. Finally, the idea of this banking desktop integrated system emerged. It provides a similar client for each staff member of a banking institution. These clients are integrated into the integrated system, and the integrated system configures roles for specific tasks. Therefore, this banking desktop system is a good example of a smart client. This client itself is also very special, we call it a complex Smart Client. Microsoft's technologies used to design and develop complex Smart Clients include
Uiapplication block) and scsf (Smart Clients software factory ). This article is about these technologies.

Part 1: Architecture guidance for complex Smart Clients

The first section describes how to create complex Smart Clients Based on cab and scsf. It helps you identify and construct complex intelligent client components and find a way to encapsulate them.

Terminology

Cab: A Flexible Assembly provided by Microsoft patterns & Practices Group to create complex and modular Smart Client Applications. This Assembly provides the following functions:

Dynamically load independent modules with collaboration relationships to a common platform;

Implement loose coupling communication between modules and between modules through event proxy;

Flexible command mode;

Implement basic classes that serve the MVC model;

A framework is established to provide verification services, authorization services, module positioning, and module loading services.

The cab application is case-driven, and each use case is implemented through MVP or MVC. The client service of the center is loaded through the basic service provided by the cab.

Workitem: Technically, workitem is a container used to manage multiple objects that implement a specific function. These objects include State objects, views, control layers, and commands. In the previous view of a workitem, it is a logical encapsulation class for a specific use case. It can be regarded as a case administrator and is clear about all aspects of the case. In this way, a workitem can grasp the status of each part related to the use case, such as views or the next-level use case. Furthermore, it is the entry point of the use case (or next-level use case) It is responsible.

Service: the service encapsulates the common functions of the entire application. These common functions may also be shared by a certain module, or multiple workitems in a level-1 workitem (for example, the lower-level workitem of the level-1 workitem ). Typically, security services such as authentication and authorization, and Web Service proxies with interactive and offline capabilities are provided.

Module: Multiple logically related workitems can be placed in a single deployment unit, that is, a module. The cab-Based Smart Client program is basically configured at the module level. Therefore, it is critical to encapsulate workitem with appropriate granularity.

Profilecatalog: this basic directory is only a configuration file, specifying which module or service needs to be loaded into the program. By default, this configuration file only resides in an XML file in the application directory. It specifies which modules need to be loaded. By writing and registering a custom imoduleenumerator class, you can specify a new location to load the configuration file, such as through web service.

Moduleloader: a common service provided by cab that loads all modules defined by profilecatalog. It just traverses the profilecatalog, loads the corresponding Assembly for each item, and finds the moduleinit class in the Assembly.

Moduleinit: Each module contains the moduleinit class, which is responsible for loading all services and workitems in the module. (In addition to services and workitems, it is also responsible for other aspects, such as expanding user interfaces for shell. For more information, see the description of uiextensionsite In the table .)

Shell application: shell applications are responsible for the initialization of the platform, which is the most important. It is responsible for loading modules and starting basic services for the smart client according to the configuration, and also for starting the main form.

Shell: it is the main form of the application, providing public user interfaces for all loaded modules. Rootworkitem stays in the shell. It is the entry to other parts of the application, such as services, modules, and workitems generated and registered by these modules.

Workspace: it is mainly responsible for placing and displaying user interface elements generated by workitem. Generally, a workspace is added to a shell (or the extended form of a workitem of this level) as part of the UI container, which will load the UI elements generated by different levels of workitem.

Uiextensionsite: it is an extension reserved by Shell for menu placement, toolbar, and status bar. Unlike workspace, they are not completely included by workitem as part of the UI; they are eXtensible (such as adding a new menu item ).

Command: it is a basic class used by CAD to implement the command mode. Cab supports custom commands or generate commands using the [commandhandler] attribute declaration method. The declared attributes are used as the command handle. You can register Multiple callers for a command (for example, multiple controls can use one click event ).

Eventpublication: Event publishing Method Based on loosely coupled events. The event publisher publishes an event using the [eventpublication] attribute in. net, which is uniquely identified by the Uris (unique string. Cab notifies the event subscriber of this URIs to subscribe to the event. The event subscriber must have a corresponding method marked by the [eventsubscriber] attribute. The method name is the same as the event name using the corresponding [eventpublication.

Eventsubication: it corresponds to eventpublication. To subscribe to an event class, you must implement an event handle and match the method name marked by eventpublication. The event handle must be described using the [eventsubencoding] attribute and the publisher's Uris (constructor parameter, in this way, the cab ensures that all its subscribers are notified every time the publisher triggers an event.

Model: it is the Business Object (client) in workitem; for example, customer, bank account or loan.

View: it is a common user control of. net. It is used to display part or the entire model, and allows the user to modify the displayed content through the interface. Typically, the view is only responsible for the logic on the interface, and the business logic is the responsibility of presenter or controller.

Smallpart: it is a. Net user control with the [smartpart] attribute and can selectively implement the ismartpartinfoprovider interface. In essence, smartpart is additional information about the control, such as the title or description.

Controller: It is responsible for the logical implementation of business objects. A controller is responsible for only one model. This model may have multiple views. See the MVC mode.

Objectbuilder: it is a basic component of cab. Like a factory, different objects are generated based on different policies or automated instance objects. The dependent objects are initialized at the same time as the objects are generated. Essentially, objectbuilder is an object factory that relies on a mixture of injection containers and Policy mode implementations.

Dependencyinjection: it is a design mode that allows you to automatically create objects through a factory or initialize attributes and members of dependent objects at the same time. Objectbuilder implements this mode.