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:
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.