What is Componentization?
|
We've chosen to start talking about "componentization" rather than "components" in this chapter because in the software industry, the latter has become a somewhat overloaded term that is frequently interpreted differently by different people. We'll try to address some of this confusion as we progress, but we'll start out on firmer ground with a discussion of what these terms mean in everyday life. In the broadest possible terms, a system that has been 'componentized' is one that's made up of units of specific functionality that work together to form the whole. Consider, for example, a personal computer. Typically, these consist of (among other things) a motherboard, a CPU, a hard drive, some memory, a video adapter, a keyboard, a mouse, and a display. All of these 'components' work together to accomplish a task. However, while there's clearly a relationship between (say) the CPU and the mouse, they:
For the consumer, one of the chief benefits of the existence of standardized PC components is that they can, for example, replace their mouse at any time, and be confident that the new one will work in the same way as the old one. Another benefit, this time for the companies creating personal computers, is that once the way that (say) the motherboard and the CPU will interact has been decided, the teams working on those two components can do so in parallel, and independently. As we'll see, both of these have direct analogies in the world of software components.
Component ConfusionWhen we talk about 'componentizing' software, we do so with the aim of achieving similar benefits as those described above. When we update a part of an application, we want to be confident that the change will not have an adverse effect on the rest of the software. When software is being developed, we want to assign different parts of the effort to different teams, but to know that the pieces will work together in the end. In practice, this can be done in a number of different ways, not all of which involve things that a software engineer might call a "component". Consider, for example, a Visual Basic .NET code-behind file for an ASP.NET page that displays the result of an SQL query in a DataGrid. The code-behind file interacts with a C++-based COM+ DLL that manages the process of connecting to the database, executing the query, dealing with any database problems, and cleaning up memory. Clearly, this solution has three 'components', but only one of them - the COM+ DLL - might actually be called a software component, at least at first. The DataGrid is more correctly termed a control, while the code-behind file is... well, just that. All the same, there are well-defined rules governing the way these three entities interact, and as long as they're followed, none of them needs to know anything about the internal workings of the others.
Class LibrariesSo, having established that there are many different entities that might reasonably be described as components, we should introduce the technique that we've chosen to illustrate and demonstrate componentization in this chapter. The examples that we'll present in the pages to follow will employ DLLs containing class libraries that were originally written in Visual Basic .NET. In Visual Basic .NET, a class library is the DLL that's produced when a class library project is compiled. The classes contained in the class libraries you write are similar to those in the .NET Framework class library, in that objects of these classes may be instantiated and used from within other applications. Class libraries are straightforward to write and easy to reference (that is, to make use of), and they meet all of the rules we previously set out for entities that take part in componentization. | ||||||||||||||||||||||||||||||||
EAN: 2147483647
Pages: 263