In Chapter 4, "Introduction to WebClasses," I said that WebClasses act as the glue between the user interface (HTML) and back-end databases or middle-tier business objects. So far, you haven't seen this in action—we've put all the business rules and class objects directly into the WebClass project. Including business and database logic inside a WebClass project is useful for training purposes, for small sites, and for initial development, but it's not the best approach for several reasons.
Consider what happens when a user makes a call to your WebClass. The server must ask the WebClassManager to create an instance of your WebClass. Obviously, the larger the WebClass, the longer it takes to load and the more resources it uses on the server. Remember, the whole point of a Web application is to get in, get the data, and get out as fast as possible.
Another problem with using WebClasses as part of the business objects or the data-access layer is that you can't replace a DLL while IIS holds a reference to it without stopping and starting the application, or in some cases, the server itself. However, you can replace individual COM DLLs called by the WebClass without stopping the application—as long as the COM DLLs run in an MTS package.
If you want a fast and scaleable site, you need to plan your code so that the WebClass obtains data from back-end business objects and formats that data to feed HTML and script to the browser. You should not access databases directly or perform complex logical processing within your WebClass.