Application Model

An application model is a set of definitions, rules and relationships that will form the structure of an application. With the move to client-server computing, it has become increasingly important to base development on a clearly defined, layered application model. Part of the reason for this is the multi-vendor, multi-platform nature of client-server engagements: since no one vendor or computing platform supplies the application's development tools, it has become critical to clearly delineate the services provided by the different contributors. The MSF application model is based on a modified three-tiered architecture, and stresses the services provided and consumed by the different layers. One advantage of a services-based model is that it encourages developers to think of applications as collections of discrete services. Communications across layers of an application are service requests, that should in principle happen via well-defined interfaces: a developer should know how to request a service (e.g., what arguments to pass to a function call), and how to handle the results (e.g., dealing properly with function return values).

With interfaces well-defined and well known, applications can become component-based, and developers encouraged to make use of existing components where possible. Custom code can be written where the business or analytical skills of a developer truly adds value, not simply because re-usable code was not available or could not be accessed.

The MSF application model proposes three layers of services, user services, business services and data services. Again, it's important to think of each layer as being a consumer of services provided by lower layers, and of providing services to higher layers. In the next section we'll discuss how this roughly maps to a three-tier architecture, and importantly, how it provides guidance for structuring the physical architecture of a Visual Basic/SQL Server application.

Application Architecture

In Figure 7, we show an example of how the MSF application model maps to a Visual Basic application.

Figure 7: An example application architecture

A number of interesting points are raised by Figure 7:

• If you haven't started segmenting your development personnel into solution builders and component builders, consider doing it. It's a good way to take advantage of the gains from specialization and division of labor, and it maps well to an increasingly accepted model of software development.
• The architectural layering approach is important for some non-obvious reasons. In particular, system optimization and scalability will be enhanced if you take this approach. For example, if all inter-layer communications take place via easily understood, well-defined interfaces (e.g., arguments passed, values returned), it's straightforward to specify to a C programmer how to write DLL routines that could replace generic Visual Basic code. Similarly, new object technologies could be taken advantage of in the same way (.OCX controls and other objects).
• Another implication of layering has to do with the age-old question of whether to keep or pitch Visual Basic prototypes. If you architect an application correctly, prototypes should almost never be throw away code. In our work, there are really only two good reasons to discard prototypes:

  1. Sometimes we'll prototype in Access. For example, a customer might want to be involved in prototype screen development, or an internal staff member with better Access than Visual Basic skills might be assigned prototype work.

  2. Sometimes the prototype does such a good job eliciting user feedback that the user-interface is changed radically. In these cases it can be less time-consuming to start from scratch than re-do the prototype.