Choices, Choices, Choices . . .
      If you're designing the high-level architecture for a new Web application, you can typically break down your application code into three logical layers. You have data access code, business logic, and presentation-tier code. In the initial design phase it's important to make decisions about how and where you're going to package the code for each of these tiers.
      Deciding where to put the data access code and the business logic should be easy for most developers. It should be written into components and distributed in COM-based DLLs. These components should then be configured into Microsoft® Transaction Server (MTS) packages if you're running Windows NT® 4.0. If you're running Windows® 2000, the components should be configured into COM+ apps. Once the components holding your business logic and data access code are in place, the presentation-tier developers can create desktop and Web-based apps. The client apps that contain your presentation-tier code should use your business objects as an entry point into your company's IT infrastructure.
      When you're designing a Web-based client application on top of Microsoft Internet Information Services (IIS), the Web server built into Windows 2000, you have a few choices when it comes to developing your presentation tier and defining the layout of your pages. However, unless you're prepared to write a custom isapi DLL, you'll need to use the ASP framework built into IIS. Active Server Pages are critical because they allow you to run server-side scripts which, in turn, allow you to activate and run COM objects in response to client requests.
      In addition to creating and invoking methods on COM objects, Active Server Pages can be used to package the content, layout details, and user-interface code behind your Web pages. But exactly how much stuff should you put into an Active Server Page?
      It depends. Some Web developers like to cram everything into their ASP code. Others developers go to great pains to minimize what they need to put in their ASP pages. Whether you take either of these approaches or something in between, one thing remains clear. Some part of your application needs to take on the responsibility of defining the user interface.
      Any nontrivial Web application must do several things. It must accept input that the user has entered in HTML forms. It must interpret its users' requests and run whatever commands are appropriate. It must generate HTML that contains page content and layout details and send it back to the browser. Whether you write this presentation-tier code for building the user interface in Active Server Pages or in binary components, the code will more than likely access built-in ASP objects such as Request, Response, and Session.
      This month, I'm going to look at three common approaches that Web developers can use to package their presentation-tier code. These three approaches all differ when it comes to characteristics such as productivity, reusability, maintainability, extensibility, and performance. When you pick one of these approaches, you will get more of some characteristics, but less of others. Any of the three can be a reasonable choice if it makes sense for the project at hand. Figure 1 lists the three approaches and provides a short description of each.
      Whatever approach you choose, you'll still be responsible for doing the same tasks. You'll write user interface-oriented code by programming against the Request and Response objects. You'll create and run business objects by instantiating MTS and COM+ components. You'll generate HTML for page content and layout and send it back to the browser. Even though the three approaches I've listed all solve the same set of problems, each one will do it differently and offer various trade-offs. So how do you choose among them?
      Ask yourself the following questions. How fast do I want to get my site up and running? Which is more important, development productivity or application performance? How important is code reuse? Am I willing to invest more time at the beginning of the development project to improve the maintainability and extensibility of my site? Do I want to be able to change various aspects of my site without recompiling any code? Your answers to these questions can lead you to making the best choice for any given project.

Visual InterDev
      Embedding your presentation-tier code into Active Server Pages using a tool such as Visual InterDev® is a process with strengths and weaknesses. On the positive side, you can create and modify the layout of Web pages really fast. You can write server-side scripts that utilize ASP objects like Request, Response, Session, and Application. You can create and run custom business objects. Finally, you can add the code and HTML to build the response page that's sent back to the browser.
      On the other hand, the Visual InterDev-based approach can be hard to manage when developing a large Web site. This is especially true if the site is constantly changing. Since all your presentation-tier code is defined and deployed in text files, it's harder to find effective reuse techniques. You don't have an object-oriented mechanism where you can encapsulate various part of your logic from other parts. Instead, each page often becomes a smorgasbord of page content, layout details, calls to business objects, and code to deal with user interaction. The most common reuse technique for a developer using Visual InterDev is to call Save As on an .asp file and then customize the copy.
      Using Visual InterDev it's pretty easy to change one page in the site, but larger site-wide changes can be more difficult. For instance, what if you want to change the background color of every page on the site? If you have redundant code across many .asp files, you have to modify every page, which compromises your site's maintainability. You might also find that you have to change many .asp files to add a new feature or visual aspect to your site. This means that the extensibility of your site is not what it could be.
      Another disadvantage of larger Active Server Pages is that they can be slow. The interpretive nature of script doesn't allow them to run as fast as compiled code. Moreover, every call that an ASP script makes to a COM object goes through IDispatch and uses late binding. This means that calls to your business object and calls to the built-in ASP objects are much slower than the same calls made from inside a compiled Visual Basic DLL. The performance degradation of late binding can be significant when a single Active Server Page is making hundreds or thousands of COM calls.

For the Binary Fanatic
      This approach is for the developer who likes to wear his "COM is Love" T-shirt day after day. He believes that all application logic should be packed into COM-style DLLs. He also believes that Active Server Pages are evil because they are not distributed in a compiled binary form. The binary fanatic makes a concerted effort to minimize what goes into the ASP pages on his site. He discovers that it's possible to minimize his entire Web site to a single page with the following code:

 <%
 Dim ProgID, req
 ProgID = "WebFramework.ClientRequest"
 Set req = Server.CreateObject(ProgID)
 req.ProcessRequest
 %>

 Sub ProcessRequest()
   ' Determine what command the user wants
   ' Instantiate and call business objects
   ' Create HTML with content and layout
   ' Send HTML back to browser
 End Sub

 MyPage.asp?Command=GetCustomerList

The WebClass Developer
      Now let's discuss WebClasses, your third choice for building presentation-tier code. WebClasses represent a framework built on top of ASP that's similar to the one I've just described. The good news is that this framework has already been built, meaning you don't have to build one from scratch. In this sense, WebClasses offer a nice productivity boost right out of the box.
      The use of WebClasses, like any other framework, involves trade-offs. WebClasses increase your productivity while limiting your flexibility and adding some additional complexity of their own. If you were to create your own framework, you might make some design decisions that are very different from those made by the WebClass architects. In other words, even though you might really want to change some aspect of how WebClasses behave, you can't. You must take the framework or leave it the way it is. Moreover, in addition to understanding the ASP framework, you must also gain an understanding of the WebClass architecture. That is, you must learn how WebClasses interact with ASP and IIS.
      The Visual Basic team designed the WebClass framework to give Web developers the ability to write code for interpreting client requests and generating dynamic Web pages. The primary design goal behind WebClasses was to replace ASP scripts with code written inside the Visual Basic IDE. When you finish developing a WebClass application, you compile all your logic into a COM-based DLL. Once the DLL is compiled, it can be installed and configured on the production Web server.
      The WebClass framework makes it easy to interpret the user's request. A WebClass appends QueryStrings onto your URLs and provides the code to route incoming requests to the appropriate procedures. The WebClass designer is based on an event-driven paradigm, which makes it easy to trigger your code from a hyperlink or a Submit button on a Web page. As you can see, the WebClass framework is a very effective command dispatch device. What's more, the framework offers a design environment that is almost as easy to use as the traditional Visual Basic forms designer. Now that's pretty nice in terms of productivity.
      Another valuable feature that the WebClass framework provides is the ability to generate HTML page content and layout details dynamically. As long as you know how to work with HTML, you can write the Visual Basic code required to parse together Web pages at runtime. Once you've built a page dynamically, WebClasses make it pretty simple to send it back to the client's browser.
      Earlier, I mentioned that you might regret compiling HTML into a DLL. A WebClass project is no exception. You don't want to be forced to recompile and redistribute a new DLL every time you have a minor maintenance chore, such as changing the title of your home page. In the custom framework discussed earlier, I described a data-driven approach to improve a site's maintainability. This approach was based on storing HTML metadata in a database. WebClasses provide a slightly different data-driven solution that's based on HTML templates.
      An HTML template is a text-based .htm file that the WebClass framework can load at runtime and stream back to the browser. This means you can create and modify your pages with a fancy page designer. It also means that you can modify the HTML templates on the production site and your changes will take effect right away.
      A WebClass can run a search and replace operation using special tags inside an HTML template. You can define page content and layout details in .htm files and then dynamically insert custom values into placeholders just before sending the HTML back to the client.
      In one respect, HTML templates are better than using HTML metadata from a database because you can work in terms of complete .htm files and use a page designer like FrontPage. However, HTML templates aren't as flexible as using a database. Storing HTML metadata in a database will give you the highest levels of maintainability and extensibility. But then again, there's nothing to say you can't use a combination of HTML templates and a database with HTML metadata on a single WebClass project.

WebClasses and Performance
      I have heard people complain about WebClass performance. Other developers who love to spout industry buzzwords claim that WebClass are not scalable. From my experience, I've seen that WebClasses can have a minor impact on performance, but this is nothing to get alarmed about. My guess is that the developers complaining about unacceptable levels of performance are not using WebClasses correctly. Here are a few tips to make sure your WebClass project isn't an underachiever.

• Don't use the wcRetainInstance setting. This causes the framework to store an apartment-threaded object in a Session variable. This will pin each client to a specific thread in IIS and severely compromise the concurrency and throughput of your application.
• Don't hold onto Visual Basic objects across requests with Session variables. This is bad for the same reasons explained in the previous tip.
• Don't deploy your WebClass DLL in an MTS package. If you do, every call to built-in ASP objects, such as Request or Response, will be a cross-process call. Register a WebClass DLL with regsrv32 or install it inside an MTS library package.
• Make sure you're not creating extra proxy/stub layers when they're not required. For instance, if a WebClass object instantiates a component from an MTS library package using the New operator or the CreateObject function, the new object will be created inside the same process, but on a different thread across a proxy/stub layer. (You can test to see if your objects are running on different threads by looking at the App.ThreadID value.) Using Server.CreateObject to create objects from a WebClass will solve this problem.

Evaluating the WebClass Framework
      In my opinion, speed and scalability should not be a factor when considering whether to use WebClasses in an application. The decision really comes down to whether you will benefit from what the framework has to offer.
      If you're using Visual InterDev as your primary Web development tool, maybe you're tired of all the redundancy across so many of your .asp files. You find yourself modifying lots of .asp files every time you want to add or remove a page from your site. When you're working with Visual InterDev, you really miss the Visual Basic IDE because it has compile-time type checking, better debugging features, and richer IntelliSense® than Visual InterDev. A custom framework such as WebClasses can offer a quick solution to these pains.
      I am a binary fanatic. I prefer putting my presentation-tier code inside COM-based DLLs. WebClasses make sense for many developers who prefer the Visual Basic IDE to Visual InterDev. However, if you have the required COM skills and you're willing to invest the time to hand-roll a custom Web framework, you can come up with something that will be more suited to your needs than the WebClass framework. If you own the source code, you make the rules. Furthermore, once you've built your framework, you can use it to build as many Web applications as you want.
      Let's examine some shortcomings of the WebClass framework to show the places where you could do better in a framework of your own. I don't like the fact that the WebClass framework lacks integration with MTS. This lack of integration stems from a design decision to make the WebClass framework-compatible with IIS 3.0. Since IIS 3.0 does not require MTS, the WebClass framework avoids any dependencies on MTS as well. This can be pretty frustrating at times. For instance, the Visual Basic IDE can debug WebClasses and it can also debug MTS components. However, a WebClass instance cannot reliably obtain its ObjectContext while running inside the Visual Basic debugger. But if you run a WebClass instance inside the real IIS runtime, it can use the ObjectContext without any problems. That's a little strange. Things would be much better if WebClasses were MTS-aware.
      There's another reason that you should be skeptical of WebClasses. The primary support for the WebClasses framework at Microsoft comes from the Visual Basic team. In many respects, WebClasses are a competitor of Visual InterDev, making their future somewhat uncertain.
      It's important to realize that WebClasses are built on top of the ASP framework. As the Windows platform continues to evolve, the ASP framework (or whatever replaces ASP) will continue to grow along with it. Will the Visual Basic team continue to maintain and extend the WebClass framework as the platform underneath changes? That's not an easy question to answer.
      Many of you probably remember the Visual Basic team enthusiastically pushing technologies such as Remote Automation and ActiveX® Documents. Recent releases of Visual Basic have only included what it took to provide backwards compatibility for these technologies. This wasn't good news for developers who used them to build production applications. Will the next release of Visual Basic provide a new, improved version of the WebClass architecture? There's a chance that the ASP landscape will change, and the code for your WebClass applications might go up on the shelves along with your collection of eight-track tapes from the 1970s.
      In closing, I want to give WebClasses their due. I know several of the WebClass architects. They are all bright and hardworking folks. If you use WebClasses, you will appreciate what they've built. If you choose to build your own custom framework, you should still examine the WebClass architecture because it has some really nice design ideas that you'll want to incorporate.
      WebClasses minimize what goes into Active Server Pages. Every client request comes through a single entry point in a COM-based DLL. WebClasses include support for appending QueryStrings onto URLs and routing incoming requests to the appropriate command. They make it easy to construct Web pages dynamically. Finally, the framework uses a data-driven approach to facilitate maintenance. In my opinion, the choice of whether to use WebClasses stems from whether you are willing and able to spend significant time to do a better job yourself.