Components, as I've defined them, are binary entities that contain one or more objects that can be used by applications. The components we can create with Visual Basic are always ActiveX servers: either in-process servers (DLLs) or out-of-process servers (EXEs). With Visual Basic 5.0, we can also create ActiveX controls, which are a more specialised form of component.
Let's review the benefits of using components, which we discussed in Chapter 1.
One of the key benefits of binary components is a high level of reuse. We can use a single component in many applications, continually enhancing and improving the component without having to recompile or redistribute the client programs. For instance, we can create an application that uses version 1.0 of a component, as shown in the figure:
If we then find that this component would be useful in another application, with minor enhancements, we can use it as shown in the next figure:
As long as we make sure the properties and methods in version 1.0 of the component are not changed as we enhance it to version 1.1, our original application can continue to use the component without change. This means that we don't need to recompile or redistribute the first application - a very important consideration if our application is installed on hundreds or thousands of client workstations.
The components that we create using Visual Basic are always ActiveX servers. This is important, because ActiveX servers can be used by many development languages and tools - even ones that we may not foresee, as we create our applications.
For instance, we may create an application where our business objects are in an ActiveX DLL. We could then create a user-interface for those objects using Visual Basic forms and controls, pretty much just like any other program. After we deploy our application (both the UI program and our DLL), someone else may create their own user interface for our DLL, perhaps using Microsoft Excel, Active Server Pages or just about any other Windows development environment.
This is a powerful advantage to us as developers. We can provide an unprecedented level of flexibility to our customers, since they can use part or all of our application as building blocks for the development of their own custom solutions. While we may provide a base application with a standard user-interface, our customers may choose to create their own user-interface - or extend our application's functionality to suit their specific needs.
The ability to create components that contain one or more objects is key to the development of applications that are highly scalable. Since version 3.0, it's been practical to develop two-tier client/server applications using Visual Basic. Using components, we're now able to create more complex applications across any number of tiers.
This is true regardless of how many physical computers are involved. Even on a single machine, we can separate our application's business functionality from the user-interface through the use of components. If our business logic is contained in business objects, and those objects are in an ActiveX DLL, then we've effectively separated our objects from any user-interface that might be created to use that DLL.
Alternatively, we might put our business objects in an ActiveX EXE, or use Microsoft Transaction Server, so that they're running on another physical machine across the network. This technique allows our applications to utilise the processing power of many machines and to minimise the amount of information that's sent back and forth over the network.
In the next section, we'll look at a specific application architecture, which we'll call the Component-based Scalable Logical Architecture (CSLA for short), that can be used on a single workstation and yet easily be converted to run across many machines on a network.