Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design—525637-004
10-15
Isolating Data From the Application
now use shared run-time libraries (SRLs), where context can be defined for the SRL
within the address space of the calling process as part of the object file construction.
This SRL function requires the use of native mode compilation tools.
Windows NT Server supports copy-on-write dynamic link libraries. In addition to
supporting caller context, these libraries are associated with a process by run-time
functions rather than being prelinked during the object file construction phase. This
facility is ideal for the run-time selection between major functional alternatives, such as
selecting TCP/IP connectivity instead of LU 6.2 connectivity. You must exercise more
care when assigning application code to such libraries, since loading and unloading of
the library may incur costs such as connecting to databases and files.
Nonnative mode NonStop operating system applications impose unnecessary
restrictions on the design of library code to target both platforms. Even with native
mode SRLs, the subtle differences in the library facilities may necessitate packaging
the application functions differently on each system. Therefore, you should take care to
ensure the independence of individual functions so that they can be easily remapped if
necessary.
Isolating Data From the Application
You should consider separating global data from application code as much as possible.
This technique, sometimes known as data encapsulation, minimizes the code that
must change to support a change in data layout. Depending on the tools you are using
and on the functions of your application, changes in data layout can be done more
easily and with less application downtime.
What Is Data Encapsulation?
The design of nonstructured programs often assumes that each program module
makes direct access to all the data that it needs, whether the data is local to the
module or whether that data is globally available to all modules. Each module must be
aware of the layout of all the data it accesses. These modules are compiled containing
the data structure definitions or, at least, assuming a data structure definition defined
by some other module. If the structure of global data needs to change, then all
modules that access that data must also change and must be compiled again. In
applications designed this way, it is very difficult to make changes to the layout of
global data without bringing down the entire application, because so much of the
application must also change.
The following text describes one way in which separating data from code can help
reduce or eliminate downtime when upgrading the layout of global data. Figure 10-1 on
page 10-16 features a call graph showing all access to global data through one data
interface module. Routines in this module, by definition, know the structure of the calls
that the module can receive from other modules and the layout of the data itself.
A change in the layout of global data requires changes only in the data-interface
module. The calls made to the data-interface module from the rest of the application do
not need to change.