Designing the Model for E-Commerce Application in Classic ASP

In developing the business tier for our application we are going to build a series of objects that we can classify as belonging to one of three distinct groups

• Infrastructure
• Service
• Data

Before we look at the precise objects we'll be building, let's discuss these general groupings.

Infrastructure Objects

Infrastructure objects provide access to the resources that an application will use. In our case, we only need to actively manage one resource - the connection to the database. The application will use more resources, like memory, disk drives, and so on, but the application framework provided by Visual Basic and the Web server (IIS) will do this for us.

One sure way of ensuring the presentation layer code is not allowed to circumvent the business rules is to never allow the ASP code direct access to any of the infrastructure objects. In our case, we do this by creating an object that is only accessible to objects in the model. In other words, this object is private to the model as a whole and the ASP code will not be able to directly access or call methods on it.

One sure way of ensuring the presentation layer code is not allowed to circumvent the business rules is to never allow the ASP code direct access to any of the infrastructure objects. In our case, we do this by creating an object that is only accessible to objects in the model. In other words, this object is private to the model as a whole and the ASP code will not be able to directly access or call methods on it.

Service Objects

Service objects provide access to application services. An application service is defined to be anything that an application can actually do. So, in our case we might have an object that can carry out operations like creating customers, deleting customers, viewing orders placed by a customer, etc. The activities outlined (for example the operation of creating a new customer) will have to conform to certain criteria - business rules.

We may decide that any object in our model can create a customer by calling the appropriate object; additionally we may decide that not only can another object call this object to create a customer but ASP code can as well. It is through these service objects that the presentation layer code can get to the business rules. We'll see more service objects in a little while.

Data Objects

Data objects define single instances of some entity in the system somewhere. This is a deliberately broad description, but in our case it nearly always refers to rows in the database. So, we may have an object to describe a single customer, or a single order, and so on. The advantage of this approach is that it lets you add a great degree of detail to the data objects.

Now we've seen the classifications, let's move on to see how we choose the actual objects we are going to put into our object model.

Choosing the Objects

Now we know what kinds of objects we are going to have in our model, we need to decide what objects will actually make up that model. To do this, we have to go through a process of deciding how the various users of the system will flow through the application. By that we mean that a user on the system will create some form of event (not the Visual Basic type) - they will do something that requires some action.

The Full Object Model for Ecommerce application

Infrastructure objects

Database - This object has a number of uses; it simplifies our database communications (which are subsequently achieved via the ADO Connection object) it provides a couple of extra functions to aid the ordering process, and allows direct access to the ADO Connection object. This object is not directly available to the ASP code.

Service objects

Catalog - This object provides access to the product catalogue. It enables creation of departments and products, and can query manufacturers, suppliers, departments, and products. It can also create instances of the Product data object.

Customers - This object manages customers. It can log a customer into the customers only areas of the site and can create new customers in the database and manage their address and credit card information.

Orders - This object manages orders. It can take a shopping basket and turn it into an order, and it can move an order through the order-processing pipeline It can also return audit trail information.

Search - This object provides a way of searching the product catalogue.

FireAndForget - This object provides a way of sending e-mails to customers and visitors at a given date and time

XML - This object provides a way of publishing data in our database as XML, and importing XML data into our system.

Data objects

Product - This object represents a single product stored in the database. It can return information about itself, get and set dynamic attribute data, and add and return up-sell/cross-sell recommendations.

Customer - This object represents a single customer stored in the database. It can return information about itself, along with stored address and credit card information and orders that have been placed.

Order - This object represents a single order stored in the database. It can return all of its information, including customer, addresses and credit cards, and the data that makes up the order.

Basket - This object represents a single cart (basket) stored in the database. Most often, this object is used to represent the current visitor's basket. It can return its contents and summary information (total price and total quantity), and it can add and remove items from itself.