http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/petshop3x.asp

Microsoft .NET Pet Shop 3.x: Design Patterns and Architecture of the .NET Pet Shop

Gregory Leake
Microsoft Corporation

James Duff
Vertigo Software, Inc.

May 2003

Applies to:

   Microsoft® .NET Framework 1.0 and 1.1
   Microsoft® Windows 2000 and Windows Server™ 2003
   Microsoft® Internet Information Services
   Microsoft® SQL Server™ 2000
   Oracle® 9i Database

Summary: Version 3.x of the .NET Pet Shop addresses the valuable feedback given by reviewers of the .NET Pet Shop 2.0 and was created to ensure that the application is aligned with the architecture guideline documents being produced by the Microsoft. (20 printed pages)

Download the Pet Shop 3.0 Installer.msi code sample.

Contents

Abstract
What is the Java Pet Store?
Microsoft .NET Pet Shop
Business Requirements
Application Data Model
.NET Pet Shop 2.0 Architecture
.NET Pet Shop 3.0 Architecture
Conclusions
Appendix A: Changes between Versions 2 and 3

Abstract

The purpose of the original .NET Pet Shop study was to take Sun's primary J2EE blueprint application, the Sun Java Pet Store, and implement the same application functionality with Microsoft .NET. Based on the .NET implementation of Sun's J2EE best-practice sample application, customers can directly compare Microsoft's .NET technology to J2EE-based application servers across a variety of fronts while learning about the similarities and differences in the recommended design patterns for building Web-based applications. The .NET Pet Shop application is now in its third revision and is designed to show the .NET best practices for building enterprise n-tier applications which may need to support a variety of database platforms and deployment models. The .NET Pet Shop 3.0 has been re-architected based on community feedback on the .Net Pet Shop 2.0 to comply with Microsoft's Prescriptive Architecture Guidance as published on MSDN. The third revision is also fully compliant with the Middleware Company Application Server Benchmark Specification, and will serve as Microsoft's entry in the upcoming Middleware Application Server Benchmark this spring: a second round of testing by the Middleware Company to compare the scalability of .NET and the J2EE platforms for building and hosting enterprise Web applications.

What is the Java Pet Store?

The Java Pet Store is a reference implementation of a distributed application according to the J2EE blueprints maintained by Sun. The sample application was originally created to help developers and architects understand how to use and leverage J2EE technologies, and how each of the J2EE platform components fit together. The Java Pet Store demo includes documentation, full source code for the Enterprise Java Beans (EJB) architecture, Java Server Pages (JSP) technology, tag libraries, and servlets that build the application. In addition, the Java Pet Store blueprint application demonstrates certain models and design patterns through specific examples.

The full Java Pet Store contains three sample applications:

• Java Pet Store: The main J2EE Blueprints application.
• Java Pet Store Administrator: The administrator module for the Java Pet Store.
• Blueprints Mailer: A mini-application that presents some of the J2EE Blueprints design guidelines in a smaller package.

The original version of the Java Pet Store was designed to work with the following databases: Oracle, Sybase, and Cloudscape. IBM has created a DB2 port of the application. The application is publicly available at the Java 2 Platform Enterprise Edition Blueprints. The premise of the main application, the Java Pet Store, is an e-commerce application where you can buy pets online. When you start the application you can browse and search for various types of pet from dogs to reptiles.

A typical session using the Java Pet Store would be:

Homepage—This is the main page that loads when the user first starts the application.

Category View—There are five top-level categories: Fish, Dogs, Reptiles, Cats, and Birds. Each category has several products associated to it. If we select Fish as the category, we might see "Angelfish" etc.

Products—If you now select a product the application will display all variants of the product. Typically the product variant is either male or female.

Product Details—Each product variant (represented as items) will have a detailed view that displays the product description, a product image, price, and the quantity in stock.

Shopping Cart—This allows the user to manipulate the shopping cart (add, remove, and update line items).

Checkout—The checkout page displays the shopping cart in a read-only view.

Login Redirect—When the user selects "Continue" on the checkout page, they are redirected to login page if they have not signed in yet.

Verify Sign In—After being authenticated onto the site, the user is then redirected to the credit card and billing address form.

Confirm Order—The billing and the shipping addresses are displayed.

Commit Order—This is the final step in the order-processing pipeline. The order is now committed to the database at this point.

Figure 1. Java Pet Store

Microsoft .NET Pet Shop

The goal of the .NET Pet Shop was to focus solely on the Java Pet Store (the administration and mailer component were not implemented in .NET). In addition to reproducing the functionality of the Java Pet Store application, two additional objectives were added:

• Compare and contrast the code and code size of a real world, best-practice application between .NET and J2EE.
• Provide data on how many users a typical, well-designed application can support when implemented in .NET and in J2EE.

Figure 2. .NET Pet Shop

The overall logical architecture of the .NET Pet Shop is given in Figure 3. The main focus of the design was to use ASP.NET Web Forms for the presentation tier which communicate to C# business components in a logical middle tier. In turn the business components access a back end database through ADO.NET and a SQL Server helper class known as the Data Access Application Block (DAAB) for more information on the DAAB and to download the full DAAB source code. Data Access is fully abstracted into a Data Access Layer (DAL), separate from the business logic layer (BLL). New with the .NET Pet Shop 3.0, we have introduced a DAL layer for both Oracle 9i and SQL Server 2000 databases. Class loading of the appropriate DAL layer occurs dynamically at runtime based on an application configuration setting in Web.Config. Note that .NET Pet Shop 3.0 uses two backend databases, and the order process involves a distributed transaction across these two databases. Using simple Web.Config application settings, users can deploy the .Net Pet Shop to work with single or multiple backend databases, and can freely mix SQL Server and Oracle backend databases with the distributed transaction handled by .NET Serviced Components using COM+ Enterprise Services.

Figure 3. .NET Pet Shop high-level logical architecture

Figure 4 shows how the Microsoft .NET Pet Shop might be physically deployed. In this case inbound network traffic is split between the two application servers using Network Load Balancing, NLB, or perhaps hardware load balancing. Once a network request has reached one of the machines in the cluster, then all the work for that request will be performed on that particular machine. The business logic and data access components will be installed as assemblies on both servers, which in essence will be identical clones of one another. If the load-balancing software is configured to use "sticky Ips," then each server can have its own session-state store, because a second request will be guaranteed to return to the server where the first request was fulfilled. For a more fault-tolerant solution, the two application servers can share a common session-state store such as SQL Server or a dedicated session server (Not shown on diagram). The type and location of the session-state store is determined by the values in the 'sessionState' child node of the 'system.web' element in the 'web.config' file for each Web site.

Figure 4. .NET Pet Shop physical deployment diagram

Business Requirements

As part of the architecture documentation for Pet Shop 3 we have laid out what we considered to be the business requirements for the .NET Pet Shop, so that developers and customers could understand some of the trade-offs we made when we made some of our design decisions for the application.

What are the functional requirements of the Pet Shop application?

• The application should enable customers to browse the company catalog by category and through key word searches.
• The application should provide customers with a mechanism to purchase multiple items through a shopping cart model.
• The application should provide a simple security model so that a customer is required to sign in before they are allowed to purchase the contents of the cart.
• The application is intended to support a high-volume enterprise-class e-commerce solution; hence the application should demonstrate the following:
  • High performance, measured in terms of supported users, and the user response time.
  • The ability to scale up by adding more processors
  • The ability to scale out by adding more machines to form a cluster
• With large Enterprise System it is likely that the application will be required to access multiple data repositories, hence the application should support distributed transactions.
• The application should allow for a flexible deployment strategy. By default the application is designed to be deployed to two physical machines, one application server and one database server but should be extensible to work in other deployment models. The application should support multiple database vendors. In this case we have chosen Microsoft SQL Server, and Oracle.
• The application should be easy to maintain, which will be measured by the lines of code in the application.

Application Data Model

Database

The database schema used in the .NET Pet Shop is ported directly from the Java Pet Store. The Java Pet Store supports several database vendor formats and so we took the schema for the Sybase application and created it in a Microsoft SQL Server 2000 instance. This required no changes to the Sybase version of the schema. With the creation of an Oracle version of the .NET Pet Shop, we took the original Oracle implementation of the Java Pet Store database.

The database has the following overall structure of tables; see Table 1:

Table 1. Database table in Pet Shop

Table Name	Purpose
Account	Represents basic customer information
BannerData	Stores the ad banner information
Category	The catalog categories (Fish, Dogs, Cats, etc)
Inventory	Product inventory status
Item	Individual product details
LineItem	Order details
Orders	The orders placed by the customer. An order contains one or more line items
OrderStatus	Order status
Product	Catalog products, each product may have one or more variants (Items). A typical variant might be male or female.
Profile	Customer user profile
Signon	Login table for customers
Supplier	Information concerning fulfillment suppliers

With version 2 of the .NET Pet Shop, the application was modified to create a scenario where a distributed transaction would be required to complete the order process. For the distributed transaction scenario, the Orders, OrderStatus, and LineItem tables have been split off into a separate database instance that could be installed on a separate machine. We have kept this distributed design pattern in the third version of the .NET Pet Shop.

Figure 5. .NET Pet Shop orders database schema

Figure 6. .NET Pet Shop accounts and products database schema

What Changes Could Be Made to the Pet Shop Table Design?

There are some changes that could be made to the schema used in the application; however, we have not made these changes in order to keep in line with the schema provided by the Java Pet Store reference implementation. These changes are listed in table 2:

Table 2. Possible improvements to the Pet Shop schema

Change	Reason
Not store HTML in tables	You may want to use different client application types, hence by storing only an image file name, rather than an image tag, in the database you can be more flexible with the client type you can deploy
Use a one-way encryption algorithm for customer passwords	Helps make the application more secure, because if any part of the system is compromised it will still be difficult to read the password. Would require the facility to reset the password to a new value.
Encrypt credit card information	Prevent access to the credit card information should the system to compromised. Additional changes would be to make the table only accessible with write permissions via a stored procedure; hence a hacker would need to access the database via an alternative set of credentials to read the data.

.NET Pet Shop 2.0 Architecture

Figure 7. .NET Pet Shop 2 Application Architecture

.NET Pet Shop 2.0 was designed to be deployed in a physical two-tier deployment and took advantage of this fact in the implementation of certain parts of the application. The application consisted of a Web tier built with ASP.NET Web Forms which used "code-behind" to separate the application HTML from the user interface code. The middle tier contained business components to control the application logic which talked to a SQL Server database through a customized version of the Microsoft Database Access Application Block (DAAB). To support distributed transactions, some of the middle tier business components were implemented using Enterprise Services. With Microsoft .NET this is the recommended way to support distributed transactions. However, not all classes extended the ServicedComponent class, as there is a performance overhead of implementing all classes as Enterprise Serviced Components. When publishing the .NET Pet Shop 2.0, which was used in the first Middleware Application Server benchmark, we received much feedback on optimizations that should be made to the architecture to make it more relevant to large-scale enterprises. The major areas of feedback included:

• Creating a completely abstracted data tier with no imports of data-specific classes in the middle tier.
• Implementing a data access layer for Oracle that works transparently with the same business and UI layers as the SQL Server version.
• Completely abstracting Web session state from the business logic and data layers such that the backend components of the application can be physically distributed onto separate computers from the Web server, or reused from other types of clients such as Windows-based clients vs. Web–based clients.
• Fully partitioning application modules into separate namespaces and physical assemblies.
• Additional feedback across a variety of fronts.

.NET Pet Shop 3.0 Architecture

Figure 8. .NET Pet Shop 3.0 application architecture

Application Areas

Table 3. Application areas in the Pet Shop solution

Area	Purpose	.NET Implementation
User Interface Components	Capture data input from the user and display data returned by the backend system. They also handle simple navigation. Refer to User Interface Components.	ASP.NET Web Forms, user controls, and server controls. These constructs allow for clean separation between designer HTML and UI code such as event handlers for buttons
User Interface Processing	Controls user navigation and process flows with backend business objects. Also handles management of user session data. Refers to User Process Components.	These are implemented as C# classes. The session state management is handled by ASP.NET.
Business Components	Components that implement the business logic for an application	These are implemented as C# classes
Business Entities	Thin data classes for passing data between tiers of the application. Refer to business entity components.	These are implemented as C# classes with each field exposed as a property. Each class is marked as "serializable" to enable inter-process transfer.
Data Access Layer Components	Handle the interaction with back end data stores, including databases, messaging systems, etc.	These handle the interaction with backend data stores, including databases, messaging systems, etc. Implemented as four C# projects: A set of interface classes for each data access method we want to expose. An implementation of the interfaces for SQL Server. An implementation of the interfaces for Oracle 9i. A set of factory classes to load the correct implementation, either SQL Server or Oracle.

Microsoft Visual Studio .NET Solution

Figure 9 shows the Microsoft Visual Studio .NET solution layout for the .NET Pet Shop application. Each element or tier of the application was given its own project to make the solution manage and clearly define where new classes used in the application should be placed or old ones can be found.

Figure 9. Visual Studio .NET application solution

The purpose of each project is listed in Table 4:

Table 4. Visual Studio projects in the Pet Shop solution

Project	Purpose
BLL	Home for business logic components
ConfigTool	Administration application used to encrypt connection strings and create event log source
DALFactory	Classes used to determine which database access assembly to load
IDAL	Set of interfaces which need to be implemented by each DAL implementation
Model	Thin data classes or business entities
OracleDAL	Oracle specific implementation of the Pet Shop DAL which uses the IDAL interfaces
Post-Build	Project to run post compile actions such as adding assemblies to the GAC or COM+
Pre-Build	Project to remove assemblies from the GAC or unregister assemblies from COM+
SQLServerDAL	Microsoft SQL Server specific implementation of the Pet Shop DAL which uses the IDAL interfaces
Utility	Set of helper classes including a wrapper for the DPAPI
Web	Web pages and controls
Solution Items	Miscellaneous items used to build the application such as Pet Shop.snk key file used to sign application assemblies

Database Portability

One of the key requirements for this version of the Microsoft .NET Pet Shop was to provide an implementation of the application that supported both Oracle and SQL Server databases. When designing the database access mechanism for the application, we had a choice as to which database providers we should use; we could either use the generic OLE-DB managed provider or the database-specific, performance-optimized .NET managed providers, such as the SQL Server and Oracle managed providers provided with the .NET Framework 1.1. One of the key requirements for the application was to create a high-performance solution, so we chose to build the application using the database-native .NET managed providers. For an analysis of the difference in performance between the managed providers and the generic OLE-DB providers, readers should refer to Using .NET Framework Data Provider for Oracle to Improve .NET Application Performance, which shows that the vendor-specific providers can perform two to three times better than the equivalent OLE-DB provider. The tradeoff that we made when choosing to go with a database-specific access class was that we would need to write a separate data access layer for each database platform we wanted to support and hence the application would contain more code. While the two data access layers share much common code, each is clearly targeted for use with a specific database (Oracle or SQL Server 2000).

In order to simplify the use of the database access classe,s we elected to use the Factory Design Pattern as outlined by the GoF, with reflection being used to dynamically load the correct data access objects at runtime. The factory is implemented as follows: a C# interface is created with a method declared for each method that must be exposed by the database access classes. For each database that we want to support, we create a concrete class that implements the database specific code to perform each of the operations in the interface or "contract." To support the runtime determination of which concrete class to load, we create a third class which is the factory itself and reads a value from configuration file to determine which assembly to load using reflection. With the reflection namespace in .NET, you can load a specific assembly and create an instance of an object using that assembly. To make the application more secure and provide improved support for versioning, we can add "evidence" about the assembly file to load in the application configuration file, in this case, web.config. This means that the .NET Framework will only load the assembly that we have signed during compilation and has the correct version number. Figure 10 shows how the business logic, factory, and databases access classes interact with each other. The key advantage of the solution built is that the database access class can be compiled after the business logic classes as long as the data access class implements the IDAL interfaces. This means that should we want to create a DB2 version of the application, we do not need to change the business logic tier (or UI tier). The steps to create a DB2 compatible version are:

1. Create the database access classes for DB2 which implement the IDAL interfaces.
2. Compile the DB2 access classes into an assembly.
3. Test and deploy the new data assembly to a running server.
4. Change the configuration file to point to the new database access classes.

No changes or recompiles need to be performed on the business logic components.

Figure 10. DAL factory implementation in .NET Pet Shop

Stored procedures

Normally we would recommend to customers that they use stored procedures to access tables in the database. There are several reasons for this:

• Stored procedures provide a clean mechanism to encapsulate queries.
• Changing a query can be done without changing the data access code.
• A DBA can easily see what SQL statements are being executed.
• Stored procedures are typically more secure, and it is easier to control database access.
• By using stored procedures you can avoid round trips to the client by issuing more than one request in the stored procedure.
• Stored procedures usually offer the best performance compared to middle-tier-generated SQL.
• Stored procedures offer an excellent way to encapsulate XML queries and XML input parameters.

The disadvantage of stored procedures is they tend to be proprietary and are not portable across platforms.

However, to make the best use of the financial investment that you have made in your database software and hardware, developers will tend to optimize the SQL used in their applications for their specific database engine regardless of whether the SQL is in a stored procedure or generated in the middle tier. A good example of this is generating unique numbers or identity numbers, as all databases support their own particular mechanisms for doing this, and so the SQL used to generate the unique number tends to be specific to the database being used. There are always alternatives, but they do not perform as fast as the proprietary solutions.

With the .NET Pet Shop we took the conscious decision not to use stored procedures in the application as this might be seen to be an unfair advantage for the .NET solution in the Middleware Benchmark. In reality the difference in performance is small because the application is relatively simple and most of the SQL statement execution plans are cached in the database. However, for purposes of the Middleware Benchmark specification, which disallows the use of stored procedures even to wrap simple SQL statements, the .NET Pet Shop 3.0 uses no stored procedures.

Caching

One of most effective ways to improve the performance of a database-driven applications is to eliminate accessing the database for every request. ASP.NET offers a variety of caching mechanisms that boost performance in most applications. The two main ways to use caching in ASP.NET are output caching and data caching.

.NET Caching Options

Page-level output caching takes the response from an ASP.NET Web page and stores the full page in a cache. The page cache is designed to work between the Web tier and the middle tier and caches the results/data of middle-tier methods, or the results of database calls in the case of two-tier apps. The first .NET Pet Shop distribution was offered in a page-level output-cached version and a noncached version. Version 3 only supports data caching but can easily be modified to support output caching. With Windows Server 2003 and IIS 6.0, certain output cached pages (those with VaryByParm="none" and the directive to Cache 'Anywhere') can also be kernel-level cached, with even faster access from Internet clients. Regardless, any output-cached page (kernel or nonkernel cached) is served extremely quickly by the Windows application server with much less resource (CPU) consumption, since no processing is actually occurring to recreate the page.

ASP.NET Output Caching

The original .NET Pet Shop application, version 1.5, also used a variation on page-level output caching, partial page caching or fragment caching to cache different regions of page. For instance, the header information that appears on the top of every page is cached. However, the header information is dependent on the user signing in (so two different versions of the page have to be cached). ASP.NET easily allows this by using the VaryByCustom attribute on the 'OutputCache' directive. Using VaryByCustom requires overriding the GetVaryByCustomString method to get a custom cache for the header.

ASP.NET Data and Object Caching

The object cache (Cache API) allows you to store the results of a method call or database query in the internal caching engine with the .NET Framework. Since you have gone further through more of the application pipeline, the data cache may not offer the same performance boost that output caching yields, since HTML pages still must be dynamically constructed on each request. However, it does offer a good compromise between fully dynamic pages and reducing the load on the database by storing nonvolatile data in the middle tier. For example, you may want to display the same piece of data differently in two Web pages, or use the cached objects or data differently in various pages of the same application.

ASP.NET Cache Monitoring

There are several ways to monitor what is happening in the ASP.NET caching system. The foremost method is to use Perfmon but you can also use a SQL Server trace to check when database access is occurring or not occurring as the case may be. To monitor the cache in Perfmon, select the Output Cache Entries and Cache API Entries counters under the ASP.NET Application performance object and add them to the Perform graph. It is also possible to monitor the turnover rate and the hit rate within Perfmon to detect whether the item is being used in the cache.

Table 5. Summary of caching options in .NET

Type of Caching	Benefits	Limitations
Output Caching	Offers best performance	Entire page output is cached
Fragment Caching (Cache user controls)	Simple to implement. Entire page output is cached	Limited to time invalidation
Cache API	Different user controls on a page can have different cache timeouts	Cached controls can be shared across pages. Need to cache each user control individually

Pet Shop Middleware Benchmark Caching Rules

The Middleware Company has defined strict rules for the benchmark application as to what can be cached and how it can be cached. Basically, page-level output caching is disallowed, but middle-tier data caching is allowed in certain places in the application. The following data was allowed to be cached; it does not need to be refreshed from the database on each request: category information, product information, item information (excluding inventory data), and some account information. In terms of inventory data, the current quantity in stock should reflect an up-to-date value whenever an item is added to the cart or a user navigates to the 'ItemDetails' page. For the account information the username and password has to be validated on every single login attempt, and the address used for billing information should always be refreshed from the database to ensure that it is up to date during a checkout process. The implication of this is that the results for most products searches and browse operations can be cached in the middle tier using a data/object cache set to expire on a given interval.

The second rule for the benchmark is that page level output caching should not be allowed; the web server should always be required to recreate the rendered HTML for a page. The reason for this is to test the ability of the application servers to generate dynamic pages, not how fast the server could pull HTML from a cache.

Pet Shop 3.0 Caching Implementation

For this version of the application, we used data caching in the code behind of the ASPX pages to cache the results of middle tier (business logic tier) requests. The following sample code shows how one would access the ASP.NET cache API to retrieve information from the cache. The example is based on the category query, category.aspx.cs, in the Pet Shop application. In the Pet Shop a user can select one of the five predefined categories of pet and view a list of animals in that category. The first thing the code does is to check to see if the data has already been cached by using the category id as a key to look up an element in the data cache. If this element does not exist, either because the data has not yet been cached, or the current cache has expired, it will return null. If the element exists, the data from the cache is pulled and cast to the appropriate type. If the data is not in the cache, the middle tier is invoked to query for the data. The results from the middle tier query are then added to the cache with an expiry time of 12 hours from now. Alternatively, we could expire the cached based on a fixed time of day, a dependency on another cache item, or by supplying a callback function which could be used to clear the cache.

// Get the category from the query stringstring categoryKey = WebComponents.CleanString.InputText(Request["categoryId"],50);// Check to see if the contents are in the Data Cacheif(Cache[categoryKey] != null){   // If the data is already cached, then used the cached copy   products.DataSource = (IList)Cache[categoryKey];}else{// If the data is not cached, // then create a new products object and request the data   Product product = new Product();   IList productsByCategory = product.GetProductsByCategory(categoryKey);      // Store the results of the call in the Cache // and set the time out to 12 hoursCache.Add(categoryKey, productsByCategory, null, DateTime.Now.AddHours(12),        Cache.NoSlidingExpiration , CacheItemPriority.High, null);      products.DataSource = productsByCategory;}// Bind the data to the controlproducts.DataBind();

Conclusions

The architecture of the .NET Pet Shop has been enhanced to provide a more flexible solution in terms of deployment options and the application is more readily customizable and adaptable to the changes in business models. Despite all these changes, the performance of the Pet Shop has remained roughly the same as the 2.0 implementation, and shows that the Microsoft .NET framework offers a viable alternative to J2EE for Enterprise solutions. Using the .NET Pet Shop and J2EE Pet Store, architects and developers can compare .NET and J2EE side by side using functionally identical reference applications that illustrate best coding practices for each platform. The upcoming Middleware Benchmark will test the new .NET Pet Shop 3.0 implementation to compare its performance to two new J2EE implementations—one based on CMP 2.0 and one based on a pure JSP/Servlet architecture with no EJBs. The testing will be conducted by the Middleware Company and published on the ServerSide with a variety of J2EE application servers. A panel of J2EE experts has been established and is overseeing this benchmark to ensure fairness across tested products and adherence to specification/best practice for all implementations. In addition, the major J2EE application server vendors have been invited, along with Microsoft, to participate by commenting on the specification, providing implementations to be tested, and being on site for tuning/optimizations and the testing process. Microsoft has opted to fully participate in this second round of testing.

Appendix A: Changes Between Versions 2 and 3

Item	Description	Reason
1	Created a database access layer (DAL).	Allows clean separation of business logic from database access code, hence we can change database vendor without changing the business logic code.
2	Created a common project for all thin data classes (models).	The model project only contains thin classes for holding data and would be used in each tier of the application as a container to transport data in. All the model classes support serialization through the [Serializable] tag to add improved support for clustering and any future changes we want to make to physical deployment.
3	Removed references to System.Web in Components project.	Good design practice as it allows middle-tier components to be used with different types of UI.
4	Changed some of the custom server controls to Web user controls; however the Pager control was left as a custom server control.	The header and banner controls contain a lot of HTML/UI content hence they are easier to maintain if they are implemented as web user controls. The Pager control deals with the manipulation of the query string and using data in viewstate, and so it is better suited being a custom server control.
5	Created an implementation of the DAL for Oracle.	To support an Oracle database we created a specific Oracle DAL that would take advantage of an Oracle specific driver
6	The DAL layer now implements a factory [GoF] to load the appropriate vendor specific DAL.	To hide which database we are using on the back end, we use a Factory method to return an interface to the DAL layer we want to use.
7	All public fields in the model class were converted to properties.	This allows the field storage mechanism to be hidden and provides a good place to add break points in code if you want to see what functions modify certain data.
8	Created a database access layer (DAL).	Allowed clean separation of business logic from database access code, hence we can change database vendor without changing the business logic code.
9	Changed all static methods to instance methods.	Response to review feedback
10	Fixed the version number in assemblyinfo.cs to a specific version to match deployment.	Allows for specifying evidence when loading an assembly in the DALFactory objects.
11	Added pre- and post-build steps to the Visual Studio .NET solutions.	This enables for running gacutil and regsvcs utilities on certain assemblies once the project has been compiled.
12	Renamed order business components based on the function they perform rather than their implementation mechanism.	More intuitive for other developers to understand what the components do.
13	Created a configuration tool to aid application setup.	The application event log source needs to be created by a member of the administrators group. The easiest way to ensure that this was done was to provide a simple tool to do this that could be run post deployment.
14	Modified code to allow different DALs to be used for the accounts and products database and the orders database.	Response to user request to be able to use a mixed-database deployment model.
15	Page output caching is added to the pages; however this will be removed for benchmarks.	Request of for demonstration of how the VaryByCustom function can be overridden to enable pages such as the header and banner controls to be cached within pages such as default.aspx.
16	Added process flow control classes to Web application.	Response to review feedback as it provides a single location to control navigation and state management for a Web domain such as accounts or shopping carts.