To start, one call and one set of network overhead. Minimal idle time-in fact, we could even make it asynchronous by telling the Buxom server where we're sitting, and she could deliver the drinks (or one of those awful public address systems, firing an event to say our burgers are cooked-there's notable service in most of the places I frequent-far too upscale). As soon as the Buxom server is free, she can dump the state of our order -all taken in as parameters on one method anyway, so no global data required-and free herself up for the next customer. Such a system will scale better, since a single Buxom server ought to be able to turn around more orders in a given period of time.
This is the ultimate statelessness. This is what MTS systems crave (using SetComplete to indicate order completion), although it can be an awkward way of thinking for some developers. It is also what most database access techniques would ideally like to achieve. In truth, most of the time we will be somewhere in between highly stateful and stateless, but at least we know what to push toward in our design.
So the responsibilities of a data access strategy or design don't begin and end at getting data out and into the database; they have to include the dataflow (now there's an IT system term you don't hear so much anymore) around the system. If that system is composed of a number of components spread across a network, an intranet, or even the Internet, this dataflow aspect can take on a great deal of significance, since it is likely to be where performance is won or lost.
Still Not Sure What Data Is Where Objects Are Concerned?
So what is data? (Nothing like getting the fundamentals out of the way early-then there's lots of time for beer.) Funny how, on a software project, if you don't get the basics right the first time, they come back to haunt you (and steal your drinking time) later in the development cycle. In the context of this chapter, Data is sadly not a character from Star Trek-the Next Generation (I know, you don't get the time to watch it, you're debugging at the moment), but variables holding specific values.
Anyone reading this who has already worked on a tiered system will know that, should you ever come to physically distribute your tiers of objects-that is to have cooperating objects working across more than one machine to constitute the system-you are faced with an object-or-data, reference-or-variable dilemma. Which should you use, raw variables or object references (and through them properties and methods)? To the purist there is no contest-use the objects. But we are pragmatists. Our jobs are on the line if excellent theory produces appalling performance, so we have to think a little before jumping.
