Useful Patterns for S C A

The following patterns for Smart Client Applications are described this section:

1. Model-View-Presenter (MVP)
2. Asynchronous Web Service Invocation with Timeout
3. Service Agent Proxy API Separation
4. Container Hierarchy
5. View Navigation
6. Workspace Hierarchy
7. UI Threading
8. Module Plug-in
9. Action Catalog
10. Service Locator
11. WorkItem Identity Publication
12. Module Interface Separation

1. Model-View-Presenter (MVP)
Separate the responsibilities for the visual display and the event handling behavior into different classes. A view class manages the controls on the form, and it forwards events to a presenter class. The presenter contains the logic to respond to the events, and in turn, manipulates the state of the view. The presenter class uses the model (frequently, this is application state that is represented by business entitles) to determine how to respond to the events.

This solution separates the responsibilities and also allows you to test the behavior without using the user interface.

Implementation - put a view, the view interface, and the presenter classes in a separate project folder

2. Asynchronous Web Service Invocation with Timeout
Use the synchronous Web request methods and the time-out property of the Web reference proxy. Create a command class that represents each Web service request. Using the command class, the user can specify a callback. Provide asynchronous operation with a command queue that executes commands on a separate thread. For each Web service request, create a command object and place the command on the command queue. The command queue immediately returns control to the caller and executes the command on a separate thread. When the command finishes execution, the command invokes the client callback on the separate thread.

3. Service Agent Proxy API Separation
Visual Studio generates a Web reference proxy class for each Web service request. This class includes public classes for types exposed by the Web service. These classes are often similar, but they are not the same as classes that exist in the client code. In many cases, the data types returned from a Web service undergo some transformation in the service agent before they are returned to the client code. At the same time, the names of the types often remain the same.

The solution is to separate the assembly that references the Web reference proxy from the service agent assembly. The client code references only the service agent assembly

4. Container Hierarchy
Not all application components require the same visibility and life cycle. A smart client application manages instances of different components, such as services, event topics, commands, work spaces, and UI extension elements. The instances that are closely related should be created together and disposed of together. The related instances of these components must be able to access each other, but they must not be able to access unrelated components.
Solution - Place related components in containers that form a hierarchy

5. View Navigation
In a multiview user interface, you frequently have to update one view as a result of a user action on a different view. For example, one view displays a list of items, and the other view displays a description of an individual item.
The solution is to make the presenters associated with the two views communicate through events.

6. Workspace Hierarchy
Create a hierarchy of workspaces that divides the visual surface of the client into nested rectangular areas

A view (a Windows Form or UI control) contains one or more workspaces. At run time, the application instructs a workspace to show a view. If the view contains its own workspaces, the view instructs those workspaces to show their views. This process continues through the entire hierarchy of workspaces

7. UI Threading
Frequently, a smart client application performs some operations on a background thread. It performs other operations on the same thread as the UI. In both cases, when an operation completes, the application must update the user interface. However, Windows applications can update UI controls only from the UI thread. In those cases, the application must marshal control back to the UI thread.
Create a private method in the view class to update the user interface. Define a delegate with the same signature as the private method. Create a public method that the presenter calls to request the view to update the user interface. In this public method, write code to marshal control to the UI thread when necessary.

8. Module Plug-in
Your composite smart client application supports multiple back-end services. You want to assign different teams to independently develop the support for each service. Additionally, you do not want developers to modify existing code to incorporate new back-end services when they become available.

The Composite UI Application Block ModuleLoaderService uses the information in the profile catalog to determine which modules should be loaded at run time. It then loads the specified assemblies.

When a new back-end service becomes available, create a new Composite UI Application Block module for the service. Deploy the assembly for the new module and an updated profile catalog.

9. Action Catalog
In smart client applications, you must conditionally execute code (an "action") based on aspects of a program that can change at run time.
An application that shows a view in a workspace only if the current user is associated with a specific role.

10.Service Locator
An application contains multiple WorkItems and services. Any WorkItem can contain only a single instance of a service type, but instances of the same service type can be placed in multiple WorkItems.

The WorkItem attempts to locate the service in its own collection of services. If it cannot locate the service type you requested, it asks its parent WorkItem to locate the service. This continues until the service is found or the root WorkItem is reached.


11.WorkItem Identity Publication
You want to access components in a WorkItem that is not the root WorkItem. It exists at a different location in the WorkItem hierarchy, and this location can be in the hierarchy of another module.

Publish events for the WorkItem for the specific changes to its state. Pass a reference to the WorkItem in the event arguments. The WorkItem can publish events and pass a reference to itself—in this way, the WorkItem "publishes its identity."

12.Module Interface Separation
You have a large smart client application that is composed of multiple modules written by different teams. Some modules have dependencies on other modules.
The problem is solved by breaking the module into assemblies
The module implementation assembly contains the implementation of your module. In this way, you can change the implementation of a module without requiring a recompilation of dependent modules. The dependent modules must be recompiled only when the interface assembly changes. Figure 2 illustrates the dependencies between modules and the interface assemblies.