IBuyAdventure.NET (IBA.NET)

If you haven't seen or used the old ASP AdventureWorks application before, don't worry. This chapter will be covering the IBA.NET application from the ground up, and you will only be porting a small subset of features from the original application. This approach will demonstrate how to use ASP.NET to create real world e-commerce applications, without getting distracted by too many application specific features that would simply dilute the goals of the chapter.

Note

If you do have access to the original AdventureWorks application, spend some time comparing the original ASP code and ASP.NET code in this chapter. Sections such as the shopping basket and page layout code really show the power and simplicity of ASP.NET.

The Target Audience

The IBA.NET application is aimed at allowing climbing enthusiasts to check out and buy the latest climbing equipment over the Internet from the comfort of their home, or tent! The application will let customers view different products grouped by category (boots, pants, tents, and so on), and enable them to add items to their shopping cart at any time. The application uses just-in-time registration, so customers can fill their shopping carts with products and not have to register or login until they actually proceed to the checkout. This approach is pretty common on most major sites like Amazon.com, and is a must-have feature in any e-commerce application today.

Scalability “ Web Solution Platform

The IBA.NET application needs to be scalable and capable of supporting hundreds, if not thousands, of concurrent users. To achieve this goal, the application has been designed according to the guidelines set by the Microsoft Web Solution Platform (http://microsoft.com/business/products/webplatform). The application therefore adopts an n- tier architecture as described by Windows DNA, where the application is split into a number of tiers for presentation, business logic, and data:

Figure 24-1:

By adopting an n-tier approach, as shown in Figure 24-1, the IBuyAdventure.NET application can easily be deployed on a single machine or multiple machines (one or more physical tiers). Using this architecture it should be possible to deploy ASP.NET pages, .NET components, and SQL Server on their own dedicated servers. All the ASP.NET pages in IBuyAdventure.NET access the back end database using a set of .NET components that enforce business logic and encapsulate the underlying database. These components are fairly thin, and for the most part, simply wrap a series of ADO.NET routines, similar to those that were covered in Chapter 8, returning a DataSet from the methods that are called to retrieve data.

Designing for Enterprise Scalability

To cater for enterprise-level scalability (the use of web farms), the application uses no ASP.NET session level state. All state is either stored client side within hidden fields, or in the back end SQL Server database. When a user first visits the site, the ASP.NET session ID is used to track users and any shopping items they add to their shopping cart. This information is stored in the database, and the session ID is used as the primary key to identify the user.

While this is not normally recommended, the transient nature of the shopping cart data makes it pretty safe. Alternatively, the application could generate a GUID and use that to track the anonymous users. After registering or logging in, any references to the ASP.NET session ID stored in the database are updated with the customer name .

By taking this approach, the application can easily be deployed in a web farm without the need to use session state that is specific to an individual server. Each web server receiving a request can simply use the session ID or user name (provided by the forms based authentication) to look up user details and cart items from a central database.

Important

'Sticky sessions' is a term used to describe ASP/ASP.NET user sessions that must always be redirected to the same front-end web server in a web farm. Generally, sticky sessions are required in applications that depend upon state stored in the Session object. This is typically a bad design decision because if the machine hosting the sticky session crashes or has to be restarted, all session state is lost and the user effectively has to start again.

Using a database to store session state (such as the shopping cart) does add a degree of overhead to the application, but makes it more resilient in the case of failures. If a web server, or two, fails during a user's request, another server can handle it and no information will be lost. If the application had used a session-based shopping cart, the customers would lose everything created during their session if the machine hosting that session failed.

Important

ASP.NET was designed around the principle that servers do fail and applications/components do leak memory and crash from time to time. By designing the IBuyAdventure application to use no session state, the application works well with the ASP.NET philosophy.