    
    
    
    
|
The Developer's Resource & Community Site |
| COM | XML | ASP | Java & Misc. | NEW: VS.NET |
| International | This Week | Forums | Author Central | Find a Job |
Beginning ASP Components
Author: Richard Anderson
Level of Difficulty: Beginner
Languages covered: ASP Components, Network Application Architecture, Interfaces and Implementation.
Pre-required reading: None
Pre-Reading
This book will teach you how to create components for use with Active Server Pages. Components allow us to do things that aren't possible with script, and they bring other benefits to our code too - things like code reuse, easier maintenance, and safer, simpler distribution. Components allow us to build stronger, more robust web applications - with better design, performance, scalability, and so on. With at least one new component in every chapter, and with case studies in Visual Basic and C++, you will learn by example how to create your own components.
In this chapter, we're going to convince you that you already know quite a bit about programming with components; we'll look at some typical scenarios in which components are used; and we'll begin to investigate the impact that component programming has on application design. By the end of the chapter, you should understand that componentization isn't just about code reuse—it implies a new way of creating applications, opening the door to techniques and technologies that aren't available in'traditional' programming. For further details about the book, and other books in our range, visit the Wrox Press Web Site.
Contents
- Starting Out With Components
- Interfaces and Implementation
- Using Components from ASP
- Different Kinds of Components
- Network Application Architecture
- Building Our First Component
- Summary
As our customers, our managers and the sales team ask for increasingly complex applications, the demands made of software developers are growing at an ever-increasing rate. Lately, the vogue for companies, quite rightly, has been to automate their business processes. Now the drive is to integrate all of these disparate systems together, often with the addition of a web interface so that access to these products and services is more widely available.
The continual growth in the adoption and expansion of computer-based systems leads to more sophisticated (or complicated) applications—some of which take years to develop, or evolve without direction into unmanageable systems that no single developer fully understands. When the system requires maintenance or an upgrade, where's the developer who built the thing in the first place? They're either 'too busy', or they've moved on to richer pastures (not uncommon in today's market). That means that some other poor developer has to bear the pain and hardship of working out where changes need to be made—and the ramifications that these changes will have on other parts of the system.
Concerns over scalability, structure and maintenance of these increasingly complex systems, coupled with the demands that are the very nature of software development, mean that something is needed to ease the burden. Components have got a lot to offer us. If you think of a component as a small, self-contained nugget of code that we write to sit at a well-defined point in a system's architecture and perform certain (related) tasks, we can begin a list of the benefits of components right here:
- Because by itself it is a lot simpler than the entire application, we can maintain it easily.
- Because it's self-contained, we can upgrade simply by taking out the old component and putting the new one in its place. The same applies to components that we discover to contain bugs.
- If it's useful elsewhere, we can reuse it—we may borrow it for our own purposes, or put it on the market.
We could go on, but we'll save that for later. The point is this: everything we've said so far is just as applicable to ASP and web development as it is to any other kind of development. Web sites are becoming more complicated: our ASP applications are being asked to incorporate the functionality of traditional applications; to centralize the point of access for end users who need to get at different applications; to handle increasing numbers of users. The fact is, we need to give components some serious consideration.
Components are already an important part of programming and software development, and the ability to build and use components is a valuable tool in any programmer's arsenal. In fact, these days, component building is arguably an essential skill.
In this chapter, we're going to convince you that you already know quite a bit about programming with components; we'll look at some typical scenarios in which components are used; and we'll begin to investigate the impact that component programming has on application design. By the end of the chapter, you should understand that componentization isn't just about code reuse—it implies a new way of creating applications, opening the door to techniques and technologies that aren't available in 'traditional' programming. Specifically we will see:
- The advantages of using components
- The basics of COM—Microsoft's Component Object Model
- An introduction to 3-tier and n-tier application development
- Examples of situations where you're probably using components already
- How to build and use our first component
The Advantages of Componentization
Consider the question, "What's the best approach to the solution of a complex problem?" Perhaps the most obvious answer is this:
- Break it up into a number of smaller parts, each of which is self-contained and can be easily understood
- Solve each of the smaller parts (or use a ready-written solution—you might have a solution lying round from a previous project, or you might buy in a third-party solution)
- Bring each of the smaller parts together to create the overall solution
This approach generally works very well—and programming is no exception. The reason is probably its simplicity—but this simplicity is the key to good software engineering and development.
COM—the Component Object Model
The good news is that there is an established technology available to us today that allows us to build our applications this way. It is called COM —the Component Object Model. COM is the software industry's favored solution for solving the complex problems relating to large applications and code reuse on the Windows platform. Using componentization, large applications can be assembled from smaller, self-contained packages of software, each of which performs a particular task.
By using components, we only need to write a small amount of application code to act as 'glue', sticking the pieces together. The 'glue' then simply calls the components into being, provides them with the information they need to do their work, and then either lets them get on with it or waits for them to produce a result. In this sense, they can be like little "black boxes" of functionality: you don't need to know how each component achieves its task; you just need to know what it's capable of doing and what values you can provide it so that it will accomplish the task it is built for.
A Couple of Analogies
If that sounds a bit esoteric, consider what happens when you need to ask the operator for your uncle's telephone number. You call the operator, and you give the name and address of your uncle. Then, they go away and do their thing... and eventually they come back with a number (or not, if your uncle has no telephone). In this sense, the operator is acting like a component-maybe the request would be programmed like this:
Dim objOperator
Set objOperator = Server.CreateObject("Operator")
Response.Write "The phone number you require is " & _
objOperator.GetNumberFor("Uncle Brian", "Chicago")
The point here is that we're not particularly worried about how the operator finds the number-we just give them the information and expect them to do the job.
As another example, think about hi-fi 'separates'. You buy an amplifier, a pair of speakers, a CD player, and you wire them all together with some leads. Then, a month later, you decide that you wanted a turntable so that you can play all your old vinyl. But you don't go out and buy a whole new system-after all, you already have an amplifier and speakers. You just expand the existing system by purchasing the turntable and plugging it into your amplifier.
In your average software house, this is how customers and the sales/marketing department think that application development works. Wouldn't it be nice if it really did?
Well, there can be a strong similarity. You may not have realized it, but you're already using COM components. For example, in your software development, you've probably already come across ActiveX Data Objects (ADO)-a set of components for data access. Or perhaps you've used the Ad Rotator component, the Content Rotator component, or some of the other components that are provided as standard with ASP?
Better still, look at the software you use every day-things like Microsoft Word and Internet Explorer. Many of these kinds of application are written using components. The Internet Explorer executable (Iexplore.exe) is only 77Kb in size; all of its sophisticated functionality is handled by numerous other components, which the executable only calls into action when necessary.
What Do Components Do for Us?
Hopefully, we've given you an incentive for wanting to learn about components. The advantages of packaging up our code into components rather than using script are numerous, and we'll outline the main ones here.
Code Reuse and Distribution
Possibly the two most common reasons for using components are:
- Breaking up a complex application into manageable chunks, as we've already discussed
- Packaging up code that you are likely to need more than once so that it can be re-used
Having written a piece of code that performs a specific function, cutting and pasting the appropriate pieces into another program can often be difficult. If you've ever done this with your own code, you'll know how tricky 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 lines. And if you've ever done it with someone else's code, you'll know that it's even harder!
When you package code into a COM component, you are automatically providing a clear definition of precisely how to use the functionality of that component. You'll still need to document it, but you won't need to do any cutting and pasting of code.
Easy Distribution
Of course, this also makes for a convenient code distribution technique. When passing your neatly packaged component 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, we don't need to know how the ADO components work in order to use them. We can just retrieve them from the Microsoft web site, install them, and let Microsoft's documentation tell us the rest.
Binary Distribution and Reuse
As we'll discuss in more detail later on, COM components are language neutral-they can be written in one language and used in another. If you ask a Visual Basic compiler to compile some C++ code, you'll see some interesting errors and it won't work. Ask a Visual Basic application to use a COM component that was written in C++, and it will work fine.
Maintenance and Replacability
Here's a case in point: if you have to do a lot of form field validation, you can write a component that performs the task for you-that way, you centralize the code in a component, and you can simply reuse it time and time again.
If you ever find a problem with your validation code, you can just correct the component and reinstall it in place of the faulty one. Drawing an analogy with our telephone operator example, this is comparable to the operator being off work. The telephone company just installs another operator as a stand-in. We, as clients, don't care which operator is on the other end of the 'phone-so long as they can do the job.
