16.1.2- Why do we Use Components?

Why do we Use Components?

So hopefully you should be persuaded by now that it's a good idea to divide the functionality of a large application into smaller sections. But one question we haven't answered yet is why we might use components to do this job. What's wrong with simply dividing the work up among a number of ASP pages, or writing a number of functions within a server-side include file, and #INCLUDE-ing the SSI into each page?

Well, in some cases there's nothing wrong with those other solutions. But there are numerous advantages that component-based solutions have over script-based solutions, and in this section we'll examine some of these advantages.

Code Re-use and Distribution

As we've already said, two common reasons for using components are:

• Breaking up a complex application into manageable chunks
• Packaging up code that you are likely to need more than once

Cutting and pasting the same piece of script into different areas of your ASP pages can be problematic. If you've ever done this with your own code, you'll know how difficult it is to remember how you originally intended the code to work – you may have to work out what each line is doing in order to select precisely the correct amount of code. If you've ever done it with someone else's code, you'll know that it's even harder! Even if you're using a prewritten script function or procedure, you need to paste it into your code or include it via an SSI – you can get problems with naming clashes or simply with the process of cutting and pasting.

When you package code into a COM component, you are automatically providing a clear definition of precisely how to call up the functionality of that component. It's still a good idea to have some documentation for the component, but you won't need to do any clumsy cutting and pasting of code.

Easy Distribution

Because there's no cutting and pasting involved, components make for a very convenient code distribution technique. Your code is neatly packaged into a file such as a .dll, which can be easily passed to your colleagues and customers. They don't need to understand the code behind it to get it to work – you just tell them what tasks it can achieve and what information they'll need to pass to it.

For example, when we use the ADO objects in our code, we don't need to know anything about the underlying code that is contained in msado15.dll, and which defines how those objects work. All we have to do to is consult Microsoft's documentation, which explains how we employ their methods, properties and events in our code.

Binary Distribution and Re-Use

Moreover, we can write a COM component using one language, and then use the compiled component using any other language that understands COM. For example, the MyTelephone.dll component (from Chapter 6 ) was written in Visual Basic, but we can use MyTelephone.dll in Visual Basic, VBScript, JavaScript, Java, C++, … in fact, in any COM-compliant programming language. That's because the compiled component (for example, the .dll file) is in a binary format, which is usable by any COM-compliant language.

Maintenance and Replacability

Suppose you've written an application that uses a number of components and some ASP pages to perform some large application, and you've sold it to a number of customers. Then, a report comes in that there is a bug in your application.

Ordinarily, this would send a chill down the spine of the average programmer. Of course, the first job is to track down the bug and fix it; but the real problem often lies in telling all your customers how to fix the bug. If the bug were in ASP script, then it would be difficult and messy to tell your customers how to fix the problem. But if the bug is in a component, then all you need to do is re-compile the debugged component, and distribute it in an executable .exe file that simply reinstalls the new component over the old one. For your customers, fixing the bug can be as simple as running the executable.

Performance Advantages

When you are executing some complicated code, then you want to reduce the time it takes to process. However, if your code is in the form of ASP or other script, then you can reasonably expect it to take a while. That's because scripting languages are interpreted. That is to say, each line of code needs to be converted into more elementary instructions (binary code) that the processor can understand, before that line can be executed. That happens every time that a script is run.

By contrast, components are usually already compiled, which means that they have already been converted into the binary format (we mentioned this a moment ago). This means that the component's methods can be executed straight away. The result is that components often execute much more quickly than plain scripts do. Set against that there is an overhead associated with calling up the component in the first place.

Hiding Sensitive Code

If you're distributing code, then you need to think about whether you want other people to see it. If they can see it, they can figure out how it works, and they can probably also tamper with it. If you're distributing script files, you're code is open to these kinds of threat.

If you get into writing components with languages such as Visual Basic or C++, then you compile the component before it can be used. By compiling the component you produce the binary representation that we mentioned a moment ago – not only does this execute efficiently but it protects your code from snoopers and code-changers.

Splitting Tasks Into Distinct Areas

If you have several developers or teams working on an application that is split up into discrete chunks, componentization makes it possible for each of the different groups to work on a different part of the application. Each task can be clearly defined, and you can specify the values that the different parts of the application need to share in order for the application to come together as a whole afterwards.

Commercially Available Components

There's an ever-growing number of components that are available commercially. This means that, when you're building your application, you don't necessarily have to create every single component that you need. If there's a component out there on the open market that's tried and tested, you can purchase that component and use it as part of your application.

The thing is to compare the cost of purchasing a ready-made, ready-tested component with the cost of developing, writing, testing and supporting a home-made component. Sometimes it pays to build-your-own; sometimes it pays to buy a ready-made component.

To get an idea of the number of components on the market today, check out some of the sites that specialize in selling components over the web. For example, try http://www.componentsource.com, http://www.serverobjects.com and http://www.greymatter.co.uk.

Sometimes Script is Not Adequate

There are some programming tasks that we cannot achieve with scripting languages. For example, making calls through the Win32 API is just not possible using scripting languages such as VBScript and JScript. There are other languages that support this functionality, such as Perl – but this does not have a strong user base within the ASP community.

Instead we can create components in languages which offer us access to these abilities, such as Visual Basic and C++, which are use more widely amongst the ASP community. We can then write components that make this functionality available to an ASP.