Datasheet

Chapter 1

Data-driven Application Architecture

Although it's an important part of the puzzle, simply getting hold of a database and knowing the

commands for retrieving and maintaining the data it contains does not guarantee the creation of an

application that can achieve the goals of modern software development. In no particular order, these are:

❑ Maintainability. The ability to add and amend functionality to an application continually, without

incurring large costs from having to revisit and re-implement existing portions of code.

❑ Performance. The application's ability to carry out its functionality responsively from the start,

so users don't have to wait for lengthy periods for processing to complete, and resources on

the machine are used responsibly.

❑ Scalability. The ability for an application to be extended in order to maintain performance

when large numbers of users are accessing it simultaneously. Obviously, the more users there

are, the more resources will be needed; scalability is the study of how rapidly the need for

resources grows in relation to the increase in users, whether this need can be satisfied, and if

so how this can be done.

❑ Reusability. The ultimate goal of software development; the ability to take functionality that

has already been implemented and drop it into other projects and systems, removing the need

for (re)development.

There have been many attempts to provide solutions to these problems, first through the introduction of

proceduralization and modularization – the splitting of code into functions and separate files – and then

through object-oriented techniques that hide the implementation from the user. Microsoft has produced

guidelines on how applications developed on its platform should achieve the goals laid out above.

You can learn more about this subject in VB.NET Design Patterns Applied (ISBN

1-86100-698-5), also from Wrox Press.

Earlier in the chapter, when we were talking about Retrieving Data from a Database, we briefly mentioned

a "three-part structure" for web applications that deal with data access. In fact, this was a preview of the

architecture that Microsoft (and many others) recommends. More formally, it's known as an n-tier

architecture, which basically means that each application has code 'layers' that each communicate only

with the layers around them. This section describes one of the most common approaches: the 3-tier

model, which consists of the following:

❑ Data tier. Contains the database and stored procedures, and data access code.

❑ Business tier. Contains the business logic – methods that define the unique functionality of this

system, and abstract these workings away from other tiers. This is sometimes referred to as the

"middle tier".

❑ Presentation tier. Provides a user interface and control of process flow to the application, along

with validation of user input.