Developing Web Applications

Why Components?

You could spend a lot of time writing scripts in ASP pages that emulate component functionality, but there are several reasons not to do so:

Script is much slower than a compiled object and will be less likely to scale to large numbers of users.
Script doesn’t separate presentation from functionality. Undifferentiated script scatters business logic throughout the application, making it hard to find bugs and increasing the cost of maintenance.
Components are inherently reusable; scripts are not. Components may also be used by other applications, such as those built in Visual Basic or C++.

Therefore, your development motto should be: The less script, the better. If you are serious about performance and application scalability, you should use components to perform the bulk of your business logic.

So, what makes a good server-side object? Generally, anything that expands the functionality of the server and scripting language is a candidate for a server-side object. Some server-side objects generate HTML that cannot be easily generated by ASP itself. Others perform server functions, like accessing the registry, sending mail, or administering a resource.

A compact memory footprint, computational speed, and multiuser re-entrancy are high priorities for server-side objects. Component stability is key, too. Memory leaks affect other applications on the server, and badly behaved components can cause IIS 5.0 to crash.

Because ASP component objects exist on the server, they should never be written to rely on user-interface elements, like dialog boxes or pop-ups. Configure components to send errors to the Event Log of Windows 2000 Server, or return detailed error information in the Err object, so problems can be reported to the user with script.