Data-driven Application Architecture

Chapter 1 - Displaying Data on the Web
byJohn Kauffman, Fabio Claudio Ferracchiatiet al.?
Wrox Press ?2002

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.

Note 

While it could be argued that all applications make use of n-tier architectures, it has become commonplace to use the term to mean an application that has multiple tiers (where 'n' is greater than two) that abstract implementation details from each other.

Data Tier, Business Tier, and Presentation Tier

The 3-tier model has become the most popular due mainly to its simplicity. It's also the basis for all other models, which tend to break down the three tiers still further. The diagram below should help you to visualize the three tiers before we move on to their description. One thing you might want to keep in mind is that in ADO.NET, datasets are regularly passed between tiers, which means that the business and presentation tiers know more about the structure of the database than they would in a 'pure' model.

Data Tier

The data tier consists mainly of the table definitions, relationships, and data items that constitute the database itself, along with any pieces of code used for retrieving information from the database in its natural format. In SQL Server, these would be SQL statements that are usually kept in stored procedures.

One of the hardest issues to address is where the data tier ends, and where the business tier begins. This problem arises because it's quite easy to implement a lot of the functionality of the business logic (business tier) in the database code (as stored procedures). Where the line should be drawn is largely dependent upon the requirements of the application; whether rapid portability to other database server products is a key concern, or whether high performance is preferable. If the former is more important, then putting the majority of the functionality in the business tier is a preferable solution, and vice versa.

In the diagram above, there is a separate item called "data access code". This may simply represent the use of ADO.NET, or it may be a separate layer of functionality that hides ADO.NET from the other layers, preventing them from needing to know what type of data store(s) are being accessed.

Business Tier

The business tier of the application is where the majority of the application-specific functionality resides. Usually, this functionality consists of calling multiple atomic actions (Read, Write, Delete commands, etc.) in order to insulate the presentation tier from the complexities of the rules that the application must conform to. This tier also generally contains any links necessary to the methods exposed by third-party systems.

Contrary to popular object-oriented principles, any components created for the business tier of web applications should be stateless - that is, they should make use of functions and procedures that take in multiple parameters, rather than having properties that allow values to be set before making method calls. In .NET, the business tier is often implemented using class libraries, as we'll discuss in more detail in Chapter 10.

Presentation Tier

The presentation tier of the application is the only portion of the system that the end user gets to see, whether it's a collection of web pages, the interface to an application such as Outlook, or even a command prompt. This tier functions by making use of the functionality exposed to it via the business tier - it can never access the database (or any other portion of the data tier) directly. In this way, it is kept from being exposed to many of the details of how the application has been implemented, and can focus on providing the most usable presentation of the information and options possible.

As stated above, the nature of data access with ADO.NET is such that on occasion, these guidelines are not strictly adhered to. Indeed, we'll make use of this fact to abbreviate some of our early examples. But as we progress through this book, you'll find this architecture cropping up again and again.

Presenting Data with Controls

Since we just talked about presentation, it makes sense to take a moment here to discuss an important new feature of ASP.NET. One of the biggest hurdles to overcome in the past has been finding a common way of presenting the information that is being returned from the business tier. In a nutshell, this problem has arisen from the differences between the stateless world of web applications, and the world of client-server applications, where large amounts of data can be kept at the client.

Quite simply, data that was suited to one interface was often not suited to the other, due to the different mechanisms that were available for presenting it. Attempts were made to bridge this gap using ActiveX controls that could be created in languages such as Visual Basic, but these were specific to Windows machines running Internet Explorer, removing a lot of the benefit of having HTML-based applications.

Thankfully, this problem has been greatly lessened in .NET by the introduction of ASP.NET web server controls. These behave like ActiveX controls when you're developing code, but by the time the user sees them in their browser, they've been converted into standard HTML elements. The main advantage in doing this is that it brings development for all platforms into line (even minority platforms such as WAP applications, through the use of mobile controls). A single source of data can be used to populate all of the different control types, which include such things as drop-down lists, check box lists, and the data grid, which is a highly versatile kind of table.

This book contains examples of working with all of the most important web server controls, starting with the first exercises in .

Data Binding to Controls

The key to allowing a single source of data to provide all controls with exactly what they need is data binding. This is a technique where, when given a data source in the correct format, the control itself decides what pieces of information are useful to it, and which are irrelevant.

Due to the highly structured nature of the .NET Framework, many different data sources can be used for data binding, as long as they implement the right interfaces. As well as datasets, standard data structures such as arrays and hash tables also fit the bill. The same types of objects that can be used to add items to a drop-down list control can also be used to populate a data grid, or any other web server control.

If similar end-user functionality was to be implemented in classic ASP, the developer would generally have to loop through a set of data, making calls to Response. Write(), and creating lines of HTML with <option> tags interspersed throughout. From this alone, you should start to get an idea of just how much the use of web server controls allows the developer to forget about the actual target language (HTML) they're developing for, and concentrate on what it is that they are trying to present to the user. The ASP.NET web server controls can even adjust themselves to support different browsers, so the need for developers to consider what platform the application will run on is also greatly reduced.

Note 

As the internal workings of the controls that .NET provides are hidden from the developer, support is not only guaranteed for current browsers, but also can be implemented for future ones without requiring changes to the applications that use them. This will largely remove the need for browser and version testing, traditionally an expensive part of the development cycle.

Custom Controls

While the controls that come built into .NET provide us with a great deal of functionality, and cater for most situations, there are always circumstances where we require something unique. After all, if applications were all the same, then there would be none left to write by now! When we find ourselves in this situation, .NET doesn't leave us in the lurch. We can create our own controls that support all of the features of the built-in ones, and more. We don't even have to write these controls from scratch, because custom controls can be created:

• By deriving a new one from an existing control, and adding the required functionality

• By composing a new custom control using two or more existing controls

• By creating a control from scratch, making use of base controls such as Tables and Input elements

Although it's not a subject we'll be pursuing further in this book - we've got enough on our plate as it is! - this aspect of ASP.NET web server controls is yet another reason to be enthusiastic about the wealth of options available for data access under ASP.NET.