Chapter 3: Planning an Architecture

This chapter lays the groundwork for the rest of the book by creating a number of basic services that will be shared among all future modules: configuration classes to process custom sections and elements in web.config, base business and data access classes, caching strategies, and more. I'll also introduce some new UI controls introduced in ASP.NET 2.0, namely the GridView control and the SqlDataSource/ObjectDataSource controls, which give you a data binding solution that's flexible and easy to use. Our job has never been this much fun before!

Problem

Our web site is made up of a number of separate modules for managing dynamic content such as articles, forums and polls, and sending out newsletters. However, all our modules have a number of common "design problems" that we must solve:

Separate the data access code from the business logic code and from the presentation code (user interface) so that the site is much more maintainable and scalable. This is called a multi-tier design.
Isolate the data access architecture so that it can allow the support of different underlying data stores — without requiring changes to the business object layer when the underlying data store. Similarly, changes to the business object or presentation layers should also be possible without changing another tier. This is called decoupling the tiers.
Design the business object architecture to expose the data retrieved by the data access layer in an object-oriented format. This is the process of mapping relational data to OOP classes.
Support caching of business objects to save the data we've already fetched from the data store so we don't have to make unnecessary fetches to retrieve the same data again. This results in less CPU usage, database resources, and network traffic, and thus results in better general performance.
Handle and log exceptions, and other important events such as the deletion of a record, to help diagnose problems in the event of a system failure, and to provide an audit trail.
Store the site and modules' configuration settings in a place that is easy to read from and write to, and provide helper classes to simplify access to these settings.
Bind many UI controls to the data retrieved by the business logic layer to minimize the amount of work needed in the UI layer, and to put the role of managing data in the business logic layer instead of the UI layer. Ideally, the UI should focus mostly on data presentation; the business logic layer should manipulate the data and apply business rules; and the data layer should only provide persistence (data storage).

The task in this chapter is to devise a common set of classes to address these problems so that the common classes can be utilized by the various modules to be covered in later chapters. Once you finish this chapter you'll have a foundation upon which to build, and you can even distribute the development of future modules to various other developers, who can leverage the same common code to build each module. ASP.NET 2.0 adds new features to help us implement (and in some cases completely implement) a solution for many of the problems mentioned previously.