ADO+ offers several advantages over previous versions of ADO and over other data access components. These benefits fall into the following categories:
ADO+ solutions can take advantage of the flexibility and broad acceptance of XML. Because XML is the format for transmitting data sets among components, any component that can read the XML format can process components. In the extreme case, the receiving component need not be an ADO+ component at all. That is, the transmitting component can simply save the data set as an XML file, transmit the component to its destination. The destination component might be a Visual Studio project, a Visual Studio solution, or any software artifact implemented in with any tool whatsoever. What's important is that the receiving component is able to accept the XML file formatted as a data set. As an industry standard, XML was designed with exactly this kind of interoperability in mind.
In the lifetime of a deployed system, modest changes are possible, but substantial, architectural changes are rarely attempted because they are so difficult. That is unfortunate, because in a natural course of events, such substantial changes can become necessary.
For example, as a deployed application becomes popular within its user community, the increased performance load might require architectural changes. As the performance load on a deployed application server grows, system resources can become scare and response time or throughput can suffer. Faced with this problem, software architects can choose to divide the server's business-logic processing and user-interface processing onto separate tiers on separate machines. In effect, the application server layer is replaced with two layers, alleviating the shortage of system resources.
If the original solution is implemented in ADO+ using data sets, this transformation is made easier. Remember, when you replace a single tier with two tiers, you arrange for those two tiers to trade information. Because they tiers can transmit data through transmit XML-formatted data sets, the communication is relatively easy.
Programmers can manipulate objects of the ADO+ model through strongly-typed programming. Strongly typed programming is programming in which the types of things that are important to users are recognized by the programming environment or programming language itself.
To appreciate the benefits of strongly typed programming, you must appreciate the difference between types of things that are of interest to programmers (design-time users) and types of things that are of interest to end users (run-time users).
For example, consider the following line of code, using conventional (not strongly typed) programming:
IF TotalCost > Table("Customer").Column("AvailableCredit")
The code contains some words that are about types of things the users consider interesting. The words "Customer" and "Available Credit" are such words. But the code also contains the words "Table" and "Column." These words refer to things that your end users do not care about. Remember that strictly speaking, your users do not directly care about tables, columns, classes, and other artifacts of the software you deliver to them. The users care about their information. Tables, columns, variable names, class names and other artifacts of software implementation are, from the user's perspective, immaterial.
In a nutshell, strongly typed programming is a style of programming in which the user words figure prominently. For example, consider the following line of code using strongly typed programming:
IF TotalCost > Customer.AvailableCredit
This line of code is equivalent to the earlier line using conventional programming. In the strongly typed code, the user vocabulary is much more evident. The prominence of the user vocabulary makes the code easier to read -- a business analyst with little or no programming experience can grasp the meaning of the condition being tested without having to filter out the programmer vocabulary present in the conventional line of code.
Besides being easier to read, the strongly typed code is easier to write. Specifically automatic statement completion can be sensitive to the user vocabulary. For example, in the following imcomplete statement:
IF TotalCost > Customer.
the text "Available Credit" appears in a dropdown list of choices for completing the statement.
For disconnected applications, ADO+ data sets offer performance advantages over ADO disconnected record sets. When using COM marshalling to transmit a disconnected data set among tiers, a significant processing cost can result from converting the values in the record set to data types recognized by COM. In ADO+, such data type conversion is not necessary.
When transmitting an ADO disconnected record set from one component to another, the receiving component must accommodate COM marshalling. That is, it must be a COM component. This restriction does not apply when transmitting an ADO+ data set from one component to another. Because the transmission of data sets occurs through XML files, and because XML is a simple text-based standard with broad industry acceptance, the receiving component has no architectural restrictions whatsoever. Thus, virtually any two components can share data sets, provided both components use the same XML schema for the format of the transmitted XML-based data set.