So far I am aware of and/or care about three ways of building IIS Applications. Each of these designs has an increasing dependency on COM objects (e.g. DLLs). The message here is, Choose a design that best fits your ability to make your own COM objects.

The 100% Script Method

This is the best way to learn about ASP, IIS and the scripting language of your choice. The programmer creates one or more .ASP files and one or more .INC files. The only COM objects used in this design are made by other parties (starting with Microsoft). This application design is the most portable as it can be transferred to any server that can run ASP.

Now for the bad bits: the biggest problem I have with this design is not having Option Explicit enforced in the INC files. The application would fail silently. The second problem is being aware that the IDE I was using sucked compared to, say, VB 6.0.

The Script as COM Glue Method

This design replaces the INC files above with DLLs (or even Java Classes for those users of Chili!Soft products). This technique requires a bit more experience but often links old code from a desktop application to an n-tier Internet solution. Say, for example, that you created your own reusable way to talk to a database via ADO and you have a VB class for it. This design demands that you compile that class into an ActiveX DLL and call it from a script. Portability in this design is someone degraded since, for example, DLLs run only in Windows.

The 99% COM Object Method

This technique has one script file calling some giant COM object that knows how to talk to IIS. For the developer raised on mature IDEs, this is the easiest way to go. In my case, I would be making DLLs, which implies a firm commitment to the Windows platform. This can make certain managers in certain IT cultures uncomfortable.