9.2 A brief introduction

A brief introduction

Every application has some kind of user interface, attached business logic and data back end. Of course, each part can have a different appearance. The interface might be a regular windows interface, a Web page, a voice interface or even an automated process or script. The data might be stored in Visual FoxPro tables, in SQL Server databases, in XML files or any other kind of storage. The business logic might be compiled into an EXE or some kind of COM component. None of these pieces are specific to three-tiered architecture. You'll find them in any kind of business application, whether it be a modern component-based Windows application or an old mainframe monster.

A modern software development approach has to be a lot more flexible and powerful than in past days. Changes must be implemented more quickly, cheaply and at a higher quality. Applications are no longer monolithic. Data sources such as ADO, SQL Server and XML must be used in addition to regular Visual FoxPro data. Different interfaces must be used, including HTML, Windows interfaces and more exotic ones (at least for Visual FoxPro developers) such as Windows CE. Even if you can do everything using FoxPro data and a regular Windows interface, your app might need to talk to other components such as Microsoft Office. On top of that, you will definitely need flexibility so you can quickly change parts of an interface or the business logic without worrying about overall project quality or going through an enormous amount of work.

The three-tiered model is designed to reduce design complexities and increase the application developer's flexibility in creating, maintaining, and redeploying applications on different platforms.

In the three-tiered approach, the interface, business logic and database layers are kept separate. This can be done in various ways. All components are compiled separately in COM components and EXEs, or the classes are simply kept in different libraries and inheritance trees, but they are still compiled into one EXE, possibly using a monolithic Visual FoxPro approach. The key is that the layers talk to each other only through a defined API and are not linked in any other way. This means that, at any time, you can modify, change, or even replace a tier, and assuming that you continue to write to the same inter-tier API keep the entire system working. The independence that you gain is the key to this approach. The rest of this chapter is dedicated to explaining, supporting, defending, and preaching about this idea.

 

The model-view-controller approach

Like many things in object-oriented development, the three-tiered architecture isn't really new. Many of the traditional object-oriented languages such as Smalltalk have been using this approach for quite a while. It was (and is) known as the "model-view-controller" design, where the "model" is the data, the "view" is the interface and the "controller" is the business logic. The Unified Modeling Language (UML see Chapter 12) replaced this terminology with the terms "user services," "business services" and "data services."