Transcript Client/Server

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
Client
•
ADO
OLE DB
OLE DB
Component
•
Component
•
OLE DB
–
Data
OLE DB
ODBC
Provider
ActiveX Data Objects
(ADO) provide business
objects to data
Re-useable Components
are built using OLE DB
Data Providers export:
–
SQL
OLE DB (new relational
or non-relational)
ODBC (existing
relational)
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
Data Access via ADO/OLE DB
Application Contains:
•User Interface
•Busness Rules
•Client Cursor
•Query Processor
Application
ADO
•Monolithic application
•Single data access interface
•Application can access new
types of data
•Application is still difficult to
maintain and extend
Simple rowset
provider interfaces
OLE DB
address: http:www.microsoft.com/oledb/
ole db
OLE DB
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 1913.87 to Resource R902
0:09.28 delete 1913.87 from Resource R910
0:09.30 Commit Transaction T000
e
Log
File
HTML
Data
Product info
specification
Download
Resources
OLE DB
ISAM
Data
OLE DB
OLE DB
Mail
Data
OLE DB
Spreadsheet
Data
SQL
Data
ADO Programming Model
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.
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.
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.