Do you know how much of a nightmare some ASP pages can
Do you know how disastrous it is to intermingle HTML with program code?
Yes, you do, I know you hate it too! Been there, seen that, you've probably
got some cool tricks to reduce the clutter in your own work. Perhaps you
use functions extensively, putting away code from out of your HTML and into
an include file? Well here's an article showing you how you can take this
principle (called information hiding) to a new dimension!
The bookstore example.
Lets take a hypothetical web site, its a library's site
detailing information about books! Books are a good example, really, because
everyone can see how online bookstores work from a customer perspective.
Books have certain attributes, here I'll list some:
Number of Pages
Of course this list is not exhaustive, try
here for an exhaustive list of attributes you can collect about books!
For our purposes it's enough. If you don't want to store your book data as
XML, a relational database is a good idea.
Before looking at how you want to store this information,
it's worthwhile modeling the objects first. You can see that I've identified
two separate objects, books and authors. Publishers or binding types are certainly
other candidates, but they would complicate the example a little too much.
As you can see, both the book and the author classes have
a common set of operations: LoadFromID, Store and Delete. Real OO purists
would start decomposing the classes here and make them share, or inherit,
these operations from another class. But VBScript can't do this, so I'll leave
this explanation for another day :) Another necessary feature is the attribute
ID. Imagine you have thousands of books and tens of thousands of authors.
A convenient way to identify individual entities is by using some form of
self-generating ID, which I've modeled here.
Here is a diagram which shows some of the data entities
you may consider when modeling your database:
The main point to notice is that the data is partially
normalized, author data is stored separately from book data. An association
table is used to create relationships between books and authors, whereby
an author may have written several books, and a book may have been written
by several authors. This principle can also be applied to the binding type
column or to the publishers name column, in practice you will want to normalize
this data too.
You may or may not like the way I name the tables and
the columns, but that's your problem :) This scheme has been very useful
for me in the past, and I'm sticking with it. Tables are named in the singular,
since they represent an entity from the real world. Columns have a prefix
denoting the data type of the field: lng: Long Integers, str Strings, dtm:
DateTime. The column prefixes are only intended to be useful to humans who
can immediately see what data type goes in the field and can make educated
guesses about how to use or format the data there. The suffix: ID is reserved
for fields which form a primary or foreign key. For a more detailed discussion
of primary and foreign keys, indexes and IDENTITY fields, you should see
the documentation which comes with your make of database.
An interesting side note is that these diagrams are as
equally useful to librarians as they are to programmers or to database administrators.
True, each group may get something additional from the diagram, but the
terms used and the relationships shown are based on real world scenarios
and need little interpretation. Avoid cryptic names and unclear associations,
they are more trouble in the long run.
OK, now we have fairly detailed information about the
application we want to build, we've even shown it to the client and had
them sign that they agree that it says what they want them to say! So lets
get down to building the application, making the Database, the HTML and
ASP pages and testing it all! Right? Wrong!
The first thing we should be doing is building the classes
which represent the two objects we've identified. This well help is to clarify
what we're doing, any changes we come up when building the objects can be
easily accommodated, since neither the database nor the ASP pages yet exist,
and therefore do not need to be re engineered.
I'm assuming you've heard of VBScript classes, and know that they are formed
within this code construct:
OK, here comes an example attribute of the book class, its ISBN number:
'Private, class member variable
'Read the current ISBN value
Public Property Get ISBN()
ISBN = m_ISBN
'store a new ISBN value
Public Property Let ISBN(p_Data)
m_ISBN = p_Data
This was the ISBN attribute. The actual value of the ISBN is stored in a
private variable, called m_ISBN. Here I also use prefixes to identify the
variable as a member of the class. Doing this allows us to check that values
written to or read from the class are never badly formatted or just plain
wrong. They are doorways to the hidden insides of the class, we can check
what's coming in and going out. Here is
the partial book class containing all of its attributes.
Now I can show you an example of how the class could be used. This is old
style, questionably useful ASP code mixed in with the HTML:
Of course, you needed reams and reams of supporting code to build the connection,
get the data out of the DB and loop through the records, outputting the values
directly into the HTML. Well here is how we create an object from our book
<% Set MyBook = new cBook %>....
You can see an improvement in the code already, it is self describing. You
can see immediately that the book's title is being placed in within the table
cell, no more remembering what is in which field of your recordset. Also,
of course, if the book doesn't yet have a title, you might need to do something
like this in old-style ASP:
strTitle = MyRecordest.Fields(1).Value
if strTitle = "" then strTitle = "no title
In an OO approach, you can put this behaviour inside the class, specifically,
in the property attribute accessor method:
Public Property Get Title()
If m_Title = "" then
Title = "not title
Title = m_Title
This cleanly separates the business rules ("if there is no title display
a message saying so") from the presentation of your information. Your
improved ASP code:
...will conform to the business requirements without messing up your presentation.
If the business rules change, and they often do, you can make the modification
in one location within your class, and not hunt through every HTML page for
every instance of where you have printed the title. Life is starting to get
much easier, but there is more!
You run into real difficulties when your DB code for reading, updating and
deleting the data is repeated all through your web site, whereever you needed
to display it. If you change the database you may need to modify lots of web
pages to reflect the changed database structure. Wouldn't it be easier if
the DB code were stored directly in the object? You would only need to write
it once, store it in your class file and reuse it wherever you use those objects
in your web site? In the object diagram above, the place to store this code
is in the operations LoadFromID, Store and Delete. I'll show you first how
this functionality can be easily used in your web pages, and then how it is
implemented in the class file.
Creating and loading a book object in ASP, then displaying the book's information
'Create an empty book object,
'Load the object's data based on an ID you get from
'Display the books's information.
Set MyBook = new cBook
No database code, no worries, everything is hidden away in the implementation
of the LoadFromID operation.
I have created a new database for this example using Microsoft Access, "vboo_pubs",
based on the example pubs database in SQL Server. It has 3 tables which interest
us, book, author and authortobook, which happily
directly correspond to the three tables in the entity relationship diagram
above. This is how I would implement the LoadFromID operation, using the vboo_pubs
Public Function LoadFromId(p_Id)
Dim rs, conn, strSQL
Set Rs = Server.CreateObject("ADODB.Recordset")
Set conn = Server.CreateObject("ADODB.Connection")
strSQL = " SELECT T.title_id, T.title, T.type, "
strSQL = strSQL & " T.pub_id, P.pub_name, T.pubdate, T.notes "
strSQL = strSQL & " FROM titles T INNER JOIN publishers P ON T.pub_id
= P.pub_id "
strSQL = strSQL & " WHERE (T.title_id = '" & p_Id &
rs.open strSql, conn, 1,3
if rs.recordcount =1 then
Me.ID = rs.fields("title_id").Value
Me.Title = rs.fields("title").Value
Me.PublishersName = rs.fields("pub_name").Value
Me.PublishedYear = rs.fields("pubdate").Value
Me.BindingType = "" ' No data available!
Me.SubTitle = rs.fields("notes").Value
Me.ISBN = rs.fields("pub_ID").Value
LoadFromId = Me.ID
mvarSaveOnTerminate = true
err.raise 1, "Item with ID " & p_ID & " was not found"
Set rs = nothing
Set conn = Nothing
To get this example working you need to have an ODBC data source set up named
"pubs", which the object uses to connect to the database.
You may have noticed that there is no error handling in this code, this is
purposely bare - bones so that you can deal with errors your self. The code
actually raises an error if it can't find the record being searched for, this
is for your web pages to deal with appropriately. Sometimes not being able
to fin a record is unimportant, other times it is critical. The class does
not know in which circumstance it is being used, and makes no assumptions
about how to deal with errors.
The LoadFromID operation is essential if you want to get the data from your
database into the object, and you have an ID. But what if you don't have an
ID, but lets say the ISBN? Well, you would create a LoadFromISBN function.
Since the two functions are different only in the SQL statement they produce,
it would make sense to start refactoring here, and put the database access
code somewhere separate from the SQL generation code. Here is the refactored
LoadFromID along with the LoadFromISBN operation.
'Loads this object's values by loading a record based
on the given ID
Public Function LoadFromId(p_Id)
dim strSQL, MyID
MyID = clng(p_Id)
strSQL = "SELECT lngBookID, strTitle, strSubTitle, strISBN, strBindingType,
strSQL = strSQL & " strPublishersName, strPublishedYear, strPageCount
FROM Book "
strSQL = strSQL & " WHERE (lngBookID = " & MyID & ")
LoadFromId = LoadData (strSQL)
'Loads this object's values by loading a record based on the
Public Function LoadFromISBN(p_Id)
strSQL = "SELECT lngBookID, strTitle, strSubTitle, strISBN, strBindingType,
strSQL = strSQL & " strPublishersName, strPublishedYear, strPageCount
FROM Book "
strSQL = strSQL & " WHERE (strISBN = '" & SingleQuotes(p_Id)
& "') "
LoadFromISBN = LoadData (strSQL)
The LoadData function is quite complicated. Since this is not a tutorial
about database connections, I have left it to be shown in the complete class
listing. Both of these functions return the ID of the book which has been
The Store and Delete operations do exactly what you expect. Suppose you want
to create a new record in the database, how would you do this in an OO way
in ASP? This is very easy to do, the hard part is coding the SQL statement,
so I'll do that for you. The interesting thing to note here, is that the Store
operation is called not just when creating a new database record, but also
when saving changes which may have been made to an existing record. You can
now do inserts and updates from a single ASP page entitled "Create /
Update Book Information":
If the page is called with a book ID, load the book object, otherwise
create an empty book object
Show the editing form, and fill it with the values from your book object.
The fields are either empty or they show the existing data
When the user submits the form, again see if you have received an existing
ID. If yes, load that book object, otherwise create an empty book object
Assign the form values to the object's properties
Call store on your book object. It runs an update or an insert operation
Here is the Store operation:
Public Function Store()
'If the book has an existing (Autogenerated!) ID, then run an insert
if Me.ID < 1 then
Dim ThisRecordID, arr1, arr2
arr1 = Array("strTitle", "strSubTitle", "strISBN",
"strBindingType", "strPublishersName", "strPublishedYear",
arr2 = Array(Me.Title, Me.SubTitle, Me.ISBN, Me.BindingType, Me.PublishersName,
Me.ID = InsertRecord("Book", "lngBookID", arr1, arr2)
'Otherwise run an update
strSQL = strSQL & " UPDATE Book SET "
strSQL = strSQL & " strTitle = '" & Me.Title & "',"
strSQL = strSQL & " strSubTitle = '" & Me.SubTitle &
strSQL = strSQL & " strISBN = '" & Me.ISBN & "',"
strSQL = strSQL & " strBindingType = '" & Me.BindingType
strSQL = strSQL & " strPublishersName = '" & Me.PublishersName
strSQL = strSQL & " strPublishedYear = '" & Me.PublishedYear
strSQL = strSQL & " strPageCount = '" & Me.PageCount &
strSQL = strSQL & " where lngBookID = " & Me.ID
Store = Me.ID
And here is the delete:
Public Function Delete
strSQL = "DELETE * FROM Book WHERE lngBookID = " & Me.ID
So we've done the hard work, and made the class. Hard work? Yes and no. It
will initially seem like a lot of work, defining the member variables, writing
attributes to access them, then writing the DB code and testing it all (hopefully
using a unit testing framework like ASPUnit).
And all this without any HTML, no web pages, nothing. But that's the beauty!
Now you can give a HTML Dude a list of the Objects attributes, and he can
make the HTML pages, whilst you go on to make and test the next class file!
And of course, because each class file looks almost exactly the same as the
previous one, you can automate the production of them! My favourite is to
define an XML structure containing all of the attributes of the class, and
then write an XSL to transform the XML into a valid VBScript class. Making
this kind of system shouldn't take more than a day, writing the XML files
for your application's classes no longer than a further day, leaving you weeks
and weeks to make funky HTML :)
So here is some of that funky HTML. Earlier, I showed a simple page used
to display a book object using HTML. Here is the page which will allow us
to edit an existing book object or to create a new one:
As we saw above, instantiating a book object and loading its attributes based
on an ID number is very simple. But how do we navigate from our book object
to the authors who wrote the book? Well, if we look at the class diagram above,
the "0..*" text on the line between books and authors says that
a book refers to zero or more authors. Also, an author has a relationship
with zero or more books. Strictly speaking, we don't really want to be managing
the data of authors who haven't written anything in our library, but the situation
occurs often in real life, when for example the author's first book has not
yet been published.
The book object has a property, called "Authors". Using object
notation we can reference the first author in the collection of the books
authors like this: Mybook.Authors.Items(1).LastName
This is how the property is built:
Public Property Get Authors()
if not isobject(m_Authors) then
set Library = New cLibrary
set m_Authors = Library.Authors
Set Library = nothing
Set Authors = m_Authors
This uses the "Lazy Load" design pattern. The book object does
not contain any authors until you actually request author information. The
property checks to see if the m_Authors collection has been initialised, if
not it initialises a new Authors object. The Authors collection is provided
by the library. The library does not have a persistent representation in the
database, it has no attributes which we want to display just yet. It does
have a large number of operations, representing the functions that a library
In our case, the operation "Library.GetAuthorsByBookID(Me.ID)"
asks the library to return all of the authors associated with a particular
book as a collection. The library uses some simple SQL to retrieve the requested
records from the database. For each record returned, the library creates an
author object and initialises the author's attributes. The author object is
then added to the collection. The library informs the book about the number
of authors created, and stores the collection in its "Authors" property.
The book requests the Authors from the library object then stores the author
collection internally for speedy future access: "Set m_Authors=Library.Authors()".
Navigating from Authors works in exactly the same way, the Author object
has a property called "Books" which represents all the books written
by the author. Requesting "Author.Books" returns a collection object,
internally the library services the request by retrieving the data from the
database, creating book objects and returning them as a collection.
It may be becoming clearer now, that writing ASP classes to model the real
world is a lot of effort up-front. This effort can be justified:
The classes produced are independent of HTML.
The classes can be thoroughly tested and verified before being used by
your HTML people.
The classes can be coded parallel to screen design or HTML prototyping
activities, allowing previously sequential project activities to be performed
The SQL is hidden away where the DBA / Developer can find it, the designer
never sees it.
The code produced is reusable. In the real world this small example may
take up to a whole day to code and test, but can then be used by several
people to actually build a real world application.
Your users get a higher quality application (faster, more reliable, more
easily modified, errors are localized more quickly, easily maintained, fewer
This tutorial has given you an insight into how ASP classes are built. Attributes
and operations have been discussed. Navigation between classes has been explored
as one of the fundamental abilities of Object-Based systems. The classes presented
here use an "Active Record" persistence pattern, each object represents
one record in an associated table in the database. The Library object was
introduced as a non persistent class which services the request of other objects.
This tutorial presents a domain model. That is, real world objects and their
associations are called the problem domain, our database, classes and web
pages are part of the solution domain. Our objects closely resembled real
world objects. There are other ways of architecting applications than by using
a domain model, but this way really does leverage the power of object based
The book and Author classes are responsible for instantiating their own data,
but as you may have seen, the library class also instantiates books and authors
en masse when creating collections. This is a conceptually "dirty"
way of doing things. It would be much nicer if the code for assigning field
values to object attributes were only in one place, the risk of bugs would
be much reduced. Unfortunately, the need for performance means that an entire
table of records must be initialised in a single step.
On the performance side, things could be improved dramatically. Each book
is instantiated separately from each author. A minimum of two database calls
are necessary to first retrieve the book data and then retrieve the authors
data. Folding this into a single call with responsibility for instantiating
both book and author data would bring noticeable performance and scalability
There is a questionable resolution of the problem originally presented: separation
of code and HTML. In order to output the object's attributes, a fair amount
of scripting is still necessary. True, we have moved away from scripting the
database and the HTML to scripting objects and HTML, but a cleaner separation
could be achieved if each object had a "Render(OutputFormat)" operation
which could make a visual representation for display in the desired output
format, for example HTML.
For a fuller understanding of how the navigation between books and authors
is implemented, a good look at the accompanying code is essential. There are
some tricks and goodies in there which will surprise and delight even the
most advanced of ASP authors :)