3-Tier Client/Server Internet Example

TIER 1 - User interface and navigation Labeled Tier 1 in the following graphic, this layer comprises the entire user experience. Not only does this layer provide a graphical interface so that users can interact with the application, input data, and view the results of requests, it also manages the manipulation and formatting of data once the client receives it. In Web applications, the browser performs the tasks of this layer. TIER 2 - Business logic Tier 2, between the interface and data services layers, is the domain of the distributed application developer. Business logic, which captures the rules that govern application processing, connects the user at one end with the data at the other. The functions that the rules govern closely mimic everyday business tasks, and can be a single task or a series of tasks. TIER 3 - Data services Shown as Tier 3 in the following graphic, data services are provided by a structured (SQL, Oracle database) or unstructured (Microsoft® Exchange, Microsoft® Message Queuing) data store, which manages and provides access to the application data. A single application may enlist the services of one or more data stores.

3-Tier Client/Server Example

Database/Back End Example

Microsoft’s Universal Data Access ActiveX Data Objects (ADO) provide business objects to data Re-useable Components are built using OLE DB Data Providers export: –OLE DB (new relational or non-relational) –ODBC (existing relational) ADO Client Component OLE DB SQL Data OLE DB Component OLE DB ODBC Provider OLE DB

Interface exposed by Data Providers Access to any type of data –Low-level interfaces for data providers –Doesn’t require data to look like SQL Component data architecture –Suitable for building individual data components Response to Universal Data Store –Integrate all types of data without requiring everything to be put in a database

ActiveX Data Objects (ADO) User’s programmatic interface to Data High-level data access objects –Provides a uniform interface to data for all business application programmers –Merges RDO and DAO “Language Neutral” –C/C++, Java, Visual Basic ®, VBScript –ISVs can redistribute Provides access to underlying Rowset –Ultimate extensibility –OLE DB and ADO clients can share data

ADO Simple rowset provider interfaces Monolithic application Single data access interface Application can access new types of data Application is still difficult to maintain and extend SQLData OLE DB SpreadsheetData address: ole db Product info specification Download Resources e HTMLData OLE DB MailData ISAMData 0:00.00 Begin Transaction T000 0:00.15 Commit Transaction T000 0:00.17 Begin Transaction T001 0:01.00 Join Transaction T001 Resource R902 0:02.07 insert 9.72 to Resource R902 0:05.17 Begin Transaction T002 0:06.92 insert 8.73 to Resource R902 0:07.18 Join Transaction T001 Resource R910 0:07.19 Join Transaction T002 Resource R731 0:09.27 insert to Resource R902 0:09.28 delete from Resource R910 0:09.30 Commit Transaction T000 LogFile OLE DB Application Contains: User Interface Busness Rules Client Cursor Query Processor Application Data Access via ADO/OLE DB

ADO Programming Model

The Parameter Object The Parameter object represents a parameter of a Command. As noted in the Command description, you can explicitly create Parameter objects and add them to the Parameters collection to avoid the often unnecessary and expensive task of going to the system catalog to automatically populate the parameter binding information. The Recordset Object The Recordset object is by far the most complex (the others are simplified considerably). This is not surprising, however, because all the cursor functionality is represented in this object. The Recordset object looks much like it does in existing models today, but a number of improvements have been made, such as removing unnecessary elements, adding optional arguments that reduce the number of lines of code for common scenarios, and changing defaults that didn't make sense in today's technologies. The Connection Object The Connection object represents a connection to the data source and allows you to execute commands. To execute any kind of command, you use the Execute method of the Connection object. If the command returns rows, a default Recordset object is created and returned. To specify a more complex Recordset, you create a new Recordset object, associate it with the Connection, and open the cursor.

Summary of the Objects The Command Object The Command object represents a command (also known as a query or statement) that can be processed by the data source. Commands can return rows or not, and if the provider is capable, can also handle parameters. The Command object is actually optional in the ADO model because some data providers cannot supply command execution, but the object is supported if the provider supports commands. Commands can be simple SQL statements (or some other language the data provider recognizes) or calls to stored procedures in the database. Commands can then be executed using the Command's Execute method, or you can create a Recordset object and associate it with the Command object when opening the cursor. The Command object includes a collection of Parameter objects, which is described below. If the provider can support commands with parameters, the Parameters collection will contain one parameter object for each parameter in the command. As opposed to past models, you can create Parameter objects and explicitly add them to the Parameters collection, thus allowing you to use well-known parameterized commands to avoid the sometimes very expensive operation of having the provider populate the Parameters collection automatically based on the system catalog.

The Field Object The Field interface represents a column in a Recordset that you can use to obtain values, modify values, and learn about column meta-data. This object is almost identical to past models, but includes some new functionality. The Error Object The Error object represents an error returned from a data source. This object is actually optional because it is only needed when data sources can return multiple errors for a single method call. If a provider does not return multiple errors for a single function call, the provider just raises the error through the normal COM mechanisms that all COM servers do when called from languages like Visual Basic.