Recall from previous discussions that a Web page can be characterized as implementing three application levels, or tiers. These tiers are
Up to this point, Web page development has been viewed as the detailed coding of all tasks—of all application tiers—necessary to carry out page processing. Server controls and XHTML code are placed on a Web page to represent the visual, on-screen appearance of the page and to supply mechanisms through which the user interacts with the page. Visual Basic subprograms and functions are coded within the script section of the page to carry out processing tasks in response to user requests. Various server controls and scripts issue SQL commands or activate stored procedures to handle data access chores surrounding the page. In other words, everything needed to carry out page processing is encapsulated on that very same page.
Web Development Issues
For small development projects it is not unusual to find all three tiers encapsulated on a single page. There is convenience in doing so; and in small shops it is likely that a single person serves as the page designer, the application programmer, and the database administrator, all expertise being confined to a single developer to create single pages containing multiple tasks spanning the three application tiers.
As Web-based applications become more complex, however, it becomes increasingly difficult to develop and maintain pages that encapsulate all three tiers. In the first place, and especially in larger shops, different groups of developers may have separate responsibilities for the tiers. One group of layout designers and graphic artists may deal exclusively with interface design issues, a second group of system designers and programmers may deal with the programming logic behind the application, and a third group of database administrators and specialists may have control over data access permissions and methods. Difficulties arise in coordinating the work of these multiple groups when producing Web pages that includes all three requirements.
A second problem that arises in larger and more complex applications is the duplication of code that results. It is often the case, for instance, that common data access and display methods appear multiple times across multiple pages. Several pages may make the same basic call to the same database and issue the same general SQL request for information to display. In other cases, the same application logic may be applied across multiple pages. In all of these cases the same basic code appears on many different pages. Not only do issues arise in faithfully reproducing the same code on multiple pages, but when changes are made in data access methods or business requirements, all instances of this code must be tracked down and faithfully changed, not a small task, even, on small projects.
The issue, then, is how best to deal with these complicating effects of larger projects and more complex code, of how best to manage the scalability of projects that grow from simple collections of all-inclusive Web pages to systems of multi-tiered applications. The solution, of course, is not to produce larger and more complex Web pages that only exacerbate the problems. Rather, the need is to decompose Web pages into smaller, more independent parts.
Developing Tier-Based Components
One of the objectives in Web page development, then, is to move away from this practice of including all processing details on all pages. The goal, instead, is to create separate software components, separate files even, which independently carry out tasks surrounding the three basic tiers of an application.
For instance, the Web page itself—the .aspx file—contains the server controls and XHTML code to produce the screen display for the user interface. The processing scripts to implement the application logic for the page are in separate files—in .vb Visual Basic files—to which processing tasks are referred from the Web page. The data access methods to retrieve or update database information for the page are in a third file, again, activated by referrals from the Web page or from script files.
A Web page is, in effect, a bringing together of processing components that physically reside in separate files. Web page development, then, becomes a process of calling on and coordinating the work of these specialized components to carry out their processing tasks to support the particular task a hand.
As implied in Figure 11-1, the Web page, the .aspx page, is the container for the user interface. Here, server controls and XHTML code appear to represent the public face of the application. Also, code is included to call upon application logic components to perform page processing. These components may be separate Visual Basic applications packaged in separate .vb files that are imported to the page when the application is put into production. In addition, server controls to perform data access call up external data access components, themselves packaged in separate files to return sets of records for display or to update databases with parameters passed to them. Application logic components, as well, may call upon data access components to perform database access associated with the business logic of the application. Thus, a Web page originates as a user interface page that calls upon external components to perform its business logic and data access tasks.
Three main advantages derive from component-based development. First, this approach means that separate individuals and separate groups can ply their trades in their separate specialties. The page designer can work on page layout and design, the programmer can implement and program business logic, and the database specialist can deal with database access, all without having to be directly involved in the production of a particular Web page. Plus, the page developer brings these specialties together on a single page without having to know the details of each.
Second, Web pages are much easier to maintain. If, for example, there is a change in database design or in the location of, or access permissions to, a database, these changes need only be made in the data access component, not to the Web page itself. Components are "black boxes" that hide their implementation details. Web pages call on these components to do their work, but are not concerned with the processing details inside these components. Therefore, major changes may take place in the components themselves, but have no impact on the pages that utilize these components.
Third, components promote sharing. Common application logic or common data access techniques can be called from all pages needing that processing without having to code that processing on all pages. There is, in effect, a separate library of processing routines that can be called upon, again, without having to know their implementation details.
Implementing Tier-Based Components
From an implementation standpoint, development of generalized, independent software components is of two varieties. What is known as code-behind development removes the application logic from Web pages and packages it into individual software classes, with public methods that can be called from Web pages to perform required processing. These classes are encapsulated as Visual Basic files composing a library of classes that can be called from any Web page. Page scripting, then, is reduced to the minimal code necessary to import classes, call methods, and handle display of any information returned from these calls.
A second variety of component development relates to database access. Again, external routines are involved to issue selection and updating requests to the database, freeing the Web page of these tasks. Web page controls and scripts issue requests for actions but do not work with the detailed code—the database connections, the SQL statements, or the procedure calls—against the database itself. These "physical" access details are encapsulated in the external routines; the page itself makes only "logical" requests for actions to take place, supplying the data or managing the results as it relates to the user interface.
In combination, application logic components and data access components comprise the middleware of Web applications. They stand between and facilitate connections between the front-end user interface and the back-end data stores that comprise Web-based systems. The following tutorials provide a brief introduction to creating Web applications based on software components.