Binder Programming and Object Model
Some data is not well-represented by a rectangular table. For example, consider an e-mail system where messages have fields such as "To:," "From:," "Received:," "Subject:," "Cc:," and so on. Each message could be represented as a row in a table, and each field as a column. However, not every message has the same fields, so not every row would have the same columns. This means the table would not be rectangular.
The e-mail system may contain folders and messages; that is, containers and contents. The containers may occur recursively, and the contents may be of arbitrary size and data type (such as text, embedded objects, and so on). Again, this type of information is difficult to express in a table.
In addition, it is sometimes useful to represent an OLE DB object with a name, such as a Uniform Resource Locator (URL).
For situations like these, OLE DB offers the Binder programming model. The Binder model associates (that is, binds or direct binds) a URL with an OLE DB object, automatically creating a hierarchy of objects if necessary.
The tasks in the Binder model are, given a URL, to find a provider binder that can process the URL and to bind the OLE DB object. The Binder programming model is represented by the hierarchy of objects shown in the following illustration:
.gif "binder object model")
The root binder object creates a provider binder object, and the provider binder can create any other OLE DB object. If the row object represents a container or contents, it can recursively create a rowset, stream, or another row object.
Because any object can create an error object, the error object is shown as an autonomous entity in the preceding illustration.
The following topics take a closer look at the OLE DB binder, row, and stream objects and their role in the Binder programming model: