New Clients with Old Servers: A Pattern Language for Client/Server Frameworks

By: K. Wolf, C. Liu
Published in: PLoPD1
Pages: 51-64

Summary: Patterns in object-oriented frameworks for Smalltalk workstations communicating with legacy host business systems.

Category: Client-Server

Pattern: Exception

Pages: 53

Abnormal or unusual conditions often occur far from the point in the execution stack where a program would naturally respond to the condition. Defining these conditions as specializations of class Exception classifies the conditions into hierarchies.

Pattern: Solitaire

Pages: 54

Some objects occur once in an application. This should be explicit in a framework, to help developers and users.

Pattern: Objects from Records

Pages: 54-55

Exchanging data between object-oriented clients and relational databases is complicated. Move the data access responsibility from the Business Object to a Record Object. The class Record is responsible for getting, setting, and committing field objects to/from a string of bytes.

Pattern: Request

Pages: 55

Client/server frameworks use different communications interfaces. These should be invisible to client applications. Clients use a request object, which atomically exchanges a collection of input records for a set of output records.

Pattern: Materialization

Pages: 55-56

An object-oriented client/server framework renders objects at the client from the server, whether or not the server supports objects. The client should be unaware of how or when this rendering occurs. Use Request and Objects from Records to transform host data to and from objects using Proxy [Gamma+95]

Pattern: Finalization

Pages: 56-57

Maintain a dependency count for an object. When the last dependent is lost, use a finalization phase.

Pattern: Identity Management

Pages: 57

To prevent a multiplicity of business objects, use an abstract File class to manage the identity of business objects. If two lookups produce the same business object, the second merely references the object instead of producing another copy of it.

Pattern: Mega-Scrolling

Pages: 58

A request may return a collection of objects too large to materialize on the client, so limit the size of the returned collection. The limited subcollection may satisfy the user; if not, issue another request for the adjoining subcollection.

Pattern: Searching for Business Objects

Pages: 58-59

Searching for business objects can be reified by defining an abstract class called Search. Search objects define the criteria that govern a search and persist after the search, available for modification and reuse.

Pattern: Dependency

Pages: 59

To provide loose coupling between model objects and their views, use Model-View-Controller [Buschmann+96] (MVC). The original MVC usually appears as just MV.

Pattern: Creating and Updating Business Objects

Pages: 59-60

You're using Materialization to apply changes to business objects. Updates must also propagate to dependent objects using Dependency. The objects are not views, but behave as views.

Pattern: Factory Method

Pages: 60

An extension of Factory Method [Gamma+95]

Pattern: Window-Keeping

Pages: 60-61

When the user dismisses a window, the window-keeper simulates closing it, then caches it. If an object subsequently requires a window of this class, the window-keeper disinters the cached window and opens it on the object.

Category: Client-Server, GUI Development

Pattern: Viewing

Pages: 61

Viewing generally uses the functions provided by a user interface toolkit. Viewing also requires Factory Method, Dependency, and Window-Keeping to overcome the problems of burdening the client with knowledge of the views of a model.

Category: Client-Server, GUI Development

Pattern: A Client/Server Framework

Pages: 61-62

An object-oriented client/server framework for communicating with a legacy host must let users locate, examine, and change or create objects. This pattern is an aggregation of Creating and Updating Business Objects, Searching for Business Objects, and Viewing.