New Clients with Old Servers: A Pattern Language for Client/Server Frameworks New Clients with Old Servers: A Pattern Language for Client/Server FrameworksBy: 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
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.
Pages: 54
Some objects occur once in an application. This should be explicit in a framework, to help developers and users.
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.
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.
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]
Pages: 56-57
Maintain a dependency count for an object. When the last dependent is lost, use a finalization phase.
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.
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.
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.
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.
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.
Pages: 60
An extension of Factory Method [Gamma+95]
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
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
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.