In this chapter we've highlighted typical software
development problems and shown how componentization
can go a long way to making our applications easier to develop and maintain.
We've taken the time to understand some of the concepts behind
componentization, including some analogies—such as the telephone operator, the
hi-fi separates, and the car component. We understood the difference between
interface and implementation, and noted that we can exchange one component in a
system with another, provided the new component offers the same interfaces as
the old one.
We've shown how the Component Object Model (COM) provides a
specification and infrastructure that allows us to develop COM objects and use
them in any language that is COM enabled. COM components can use, and be used
by, any other COM-enabled language or environment—which makes COM extremely
powerful. We've also explained how interface-based programming is central to
We looked at how components are identified—via a GUID or
ProgID—and that COM uses the registry to store and access this information. We
suggested an informal categorization of components, in order to try to
understand more about where componentization can be applicable. We also took a
first look at 2-tier and 3-tier architecture. Finally, we saw how to implement
a COM component using the WSC, and used within an ASP page.
That's quite a lot for one chapter! In the next chapter,
we'll be consolidating our foundation on COM, and components in ASP, and we'll
create and deploy our first Visual Basic component for ASP.