Summary

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

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.