The key to developing successful client/server applications is to develop the objects within it using the business rules. Allowing a programmer to create their objects as they go along, without understanding the ultimate needs of the application and the business it must support, leads to long term maintenance and expansion problems. Any team developing client/server applications, or any other programs, needs to talk to the business team, so that they are aware of the problems they face, and the solutions they need.
As an example, imagine building a house. If it was built according to the builder's needs, i.e. speed, ease of construction, and minimum cost, the house would be the functional and not overly complex. However, the people who actually live in the building may find it confining, unsuitable for their domestic requirements, and when it comes time to redecorate they may find it too expensive to realize their wishes.
But didn't the team leader at your last project meeting say that the current main aims of the project were speed, ease of construction, and minimum cost?
This is an absolute requirement. You must begin by designing your application and not just start building parts of it to see what happens. Grab a book on client/server systems design (Grady Booch's work is the 'bible'), read and analyze the examples, and then develop. Good design, which matches the needs of the business, will ensure that the application will be maintainable and expandable, and as a by-product the debugging requirements will fall dramatically.
The key to good design is developing the applications as components, be they individual pages, HTML files, or compiled standard or custom components. Active Server Pages allow even script code to be built into modules and used as required. Remember the Server-Side Include command #include? We can use this to insert any file into an ASP file, and it's an ideal way of storing functions and subroutines as text files that are used by several other pages:
<!-- #INCLUDE FILE="MyFunction.inc" -->By defining and maintaining the same interface, (i.e. names and parameters of the routines it contains) we can update them as required, without affecting the pages that use them.
Active Server Pages isn't supported by a very efficient debugging environment, and they are still interpreted at run-time. So it makes sense to move much of the standard functionality into components where possible. Using small well-defined components can speed up the entire development process, and the execution speed of the application. It has other advantages as well, as you see discussed in Chapter 10. For example we can update the component, and all the pages that use it will automatically take advantage of the changes. It also gives us the opportunity to encapsulate secret business rules inside the component, rather than as script in a page.
The question is how do we define a small component? In reality what we want is the minimum code and the optimum functionality—based on a business rule or business object. Remember, we may have many instances running at a time if they are created at page or session level.
We saw how we can use the Application object and VBScript code to maintain a count of visitors to our site, by counting new sessions. There is, however, a problem with this. The contents of the Application object are lost when it is destroyed, i.e. when the application ends. This may be when the Web server is stopped, or in future when all active sessions have ended. So we need to consider some more solid way of saving the data.
The Microsoft IIS Web site contains a sample page counter component that neatly demonstrates the principles of component design. It's written in C++, and is reasonably compact in code terms. It also has added functionality in that it can maintain a count of accesses to almost as many different pages as we like. The details of the 'hits' to each page are stored in a text file on the server's disk. Before the server shuts down, and at undetermined intervals while it is running, the component updates this file from a memory-based cache of hit counts.
The component is instantiated on any page for which a count is required—it can't be created at session or application level like most other components because it uses the URL of the current page (where it is running) to identify the page:
Set MyCount = Server.CreateObject("IISSample.PageCounter")
This is all that's required to maintain the hit count. Each time the page is accessed by the server, the count is incremented. To get the count for the current page, we just use the Hits method:
Response.Write("You are visitor number " & MyCount.Hits)
To reset the counter for the current page, we just call its Reset method. So this is a simple but highly efficient component, packaged up and available to be dropped into a page easily. You can get a copy from:
http://www.microsoft.com/iis/usingiis/developing/samples