Figure 8-3. The distributed application architecture
As you can see, this architecture is basically the client/server
architecture with a special place for application logic—the
middle tier. This small difference, however, represents a major
philosophical shift from the client/server design. It says, in short,
that it is important to separate application logic from other kinds
of logic.
In fact, placing application logic in the database or in the UI
hinders your application's ability to grow with
changing demands. If, for example, you need a simple change to your
data model, you will have to make significant changes to your stored
procedures if your application logic is in the database. A change to
application logic in the UI, on the other hand, forces you to touch
the UI code as well and thus risk adding bugs to systems that have
nothing to do with the changes you are introducing.
The distributed application architecture does two things. It provides
a home for application processing so that it does not get mixed in
with database or UI code. However, it also makes the UI independent
of the underlying data model. Under this architecture, changes to the
data model affect only how the middle tier gets data from and puts
data into the database. The client has no knowledge of this logic and
thus does not care about such changes.
The distributed application architecture introduces two truly
critical elements. First of all, the application logic tier enables
the reuse of application logic by multiple clients. Specifically, by
abstracting out the application logic with well-defined integration
points, it is possible to reuse that logic with UIs not conceived
when the application logic was written.