Visual Basic —

Data-the Currency of an Object System

The flow of data from object to object in a distributed system is the currency of the system. It's the oil that turns the cogs of functionality. Where is an object? An object is instantiated on a given machine, and that is always where it stays (well, almost always-see "Remoting" later). One object manipulates another via an object reference, making calls on that object reference to its properties and methods. Those properties and methods -the object's interface-provide access to the object's uniqueness (its data). This is a paradigm much easier to grasp and use than an API (application programming interface) is. The object reference is essentially a pointer (4 bytes) to the object. The object doesn't move, therefore referring to an in-process object is fast, an out-of-process object is slower, and a cross-machine object much, much slower. If you want to assess the difference for yourself, the TimeIt application (see the TimeIt subdirectory in the samples directory for this chapter) has some test cases that will allow you to try this, or you can add your own. You can even try the Application Performance Explorer that ships with Visual Basic. In the cross-machine scenario, the pain in the butt is that each call to a property or a method is a piece of traffic across the network (consider also the effect of ByVal and ByRef choices for parameters on methods, as illustrated in the table below). This is going to slow your application down.

Location of component Type of argument Recommendation
In-process Large strings (not modified) Use ByRef because it uses a pointer rather than creating a copy and passing it.
Out-of-process Large strings (not modified) Use ByVal because ByRef data is copied into component's address space, this method passes a pointer to the local data, and this doubles the network traffic.
Out-of-process Object reference Use ByVal because this means you have one way cross-process marshalling, which is fast.
Out-of-process Object reference that is going to be replaced Use ByRef so that the original reference can be changed.
Out-of-process Most things Use ByVal-if you use ByRef you can't avoid marshalling by parenthesizing the parameter, or using ByVal when calling the method.

Table 12-2 Talking with components: ByVal or ByRef ?

Discussions of how to make a system faster also throw an interesting sidelight on the evolution of a programming language. In early versions of a language, your biggest goal is to make it work at all. Often there are only one or two ways to achieve the functionality in the early versions of a language, and to achieve those you have to put in some hours. There are lots of clearly wrong answers and a few clearly right answers. So if it works, you must have built it right. Then features are added to the language. These sometimes add functionality but more often diversify-more ways to skin the same old cats.

Developers are diverse too, and they react differently to the widening of their choices. Some stay with the same old tried, trusted, and understood ways. Others try every new feature, compare each to the old ways, and make decisions about how and when they will use them. Still others read a bit and wait to be directed by industry opinion. It is hard because Visual Basic has grown exponentially. But enough of sidetracks and musings.

How does this affect the data access strategy task we've set ourselves? Well, unless you are very lucky your data source will be large, shared, and on a different machine and dangerous. You can create your data-retrieving objects locally (on the user's client machine, the sink client) or remotely via a component on the server. The old computer adage, "do the work near the data," may influence you here, as will whether you have middle-tier objects out on the network. If you have remote objects, you have to consider whether to pass object references or variables, or something else.