Download Active Data Objects

Active Data Objects - ADO.NET
The Problems
How do you create a set of classes that allow software to connect to a range of
different data sources stored on remote and local machines without having to write a
new conduit for every database type?
As with many features of .NET we use a group of classes together. We shall start by
looking at the OleDB ADO.NET classes and then look at the SQL server optimised
classes.
Overview of ADO.NET Classes
System.Data.OleDb.OleDbConnection
The connection object is used to create a connection between our code and the
database
System.Data.OleDb.OleDbCommand
Used to store a command to be applied to the database
May be either raw SQL or a stored procedure
System.Data.OleDb.OleDbParameter
Used to model parameters passed to the stored procedures / queries
System.Data.OleDb.OleDbDataAdapter
Used to fill a data table with the results of a command
System.Data.DataTable
Used to model data obtained from the database
We are also going to take a look at data readers even though they are not used on the
module.
Connected Model v Disconnected Model
On a local area network when we have a shared database if a user opens a record there
is typically some mechanism for locking that record.
We want to avoid the situation where...

User A opens a record




User B opens the same record and makes changes
User B saves the changes on the record
User A makes their changes to the record
User A now saves their changes and overwrites the changes made by User B
Typically in a local area network we maintain a lock on the record stopping other
users making changes while we have the record. On a local area network it is easier to
tell via the network operating system if the lock should be maintained.
For example should a lock be maintained on a record if one of the client computers
has crashed?
Disconnected Data
The problem we have in web applications is that it is difficult maintaining such a lock.
When a client application access a record it communicates with the server via the
HTTP request. The server locates and processes the data returning it to the client at
which point the connection is lost.
This disconnected model poses certain problems in locking records.
For example




User A opens a record on the browser, the server locks the record to stop User
B accessing it
User B tries to access the record and is presented with a message stating that
the record is locked
User A is in the middle of editing the record and his browser crashes thus not
telling the server he is done with the record
User B sits there waiting and waiting for the record to come free!
We could add on a time out such that the record becomes free after a period of time
but what happens in the following scenario?




User A opens the record and goes and makes a cup of tea
The lock times out
User B opens the record
What does User A do with their data when the save the changes?
At the moment I am not looking at solutions to these problems, simply raising them as
issues to consider and also to highlight the nature of connected and disconnected data.
OleDb v SQL Optimised Classes
ADO.NET comes in two main flavours.
Object Linking and Embedding Databases OleDB
OleDB is a technology devised by Microsoft for connecting to a wide range of
database management systems (DBMS), e.g. Access, Oracle MySQL.
The set of classes provide a common interface to the various DBMS’.
The second flavour of ADO.NET is the SQL optimised version.
SQL Optimised Classes
These classes perform in exactly the same way as the OleDB classes but they have
been fine tuned to work with SQL server.
It is worth pointing out the syntax for the declarations...
For example we may declare a connection object like so :
OleDb
OleDbConnection connectionToDB = new OleDbConnection ();
SQL
SqlConnection connectionToDB = new SqlConnection();
All that changes in the code is SQL to OleDb and v.v.
The classes also have different namespace...
using System.Data.SqlClient;
and
using System.Data.OleDb;
The Execute Function
What we are going to do is pick apart the code for the data conduit and look at how
the different classes work together.
The code for this function is as follows (note I have modified the data conduits in
more recent versions to tidy up the code)...
The first object we need to set up is the connection object.
//initialise the connection to the database
connectionToDB = new OleDbConnection(connectionString);
The connection object is responsible for handling the connection between the class on
the server and the database file.
Class (Data
conduit)
Database
(File or Server)
DSN / DSN(less) Connections
Notice that the database may be file on the disk (the way that we have been
connecting to the database in this module!) Or the database may be running on a
server with an IP address on a specific port number (remember TCP/IP allows a
program on one computer to talk to another!)
There are also a large number of options to consider when connecting to the database.
Data Providers
A data provider is a software driver that “talks” to the database directly on our behalf.
In order to connect with a database we need to make sure that the correct provider or
driver is being used.
In the context of our architecture the provider sits as follows...
Presentation
Layer
Middle tier
Data layer
Our classes
Data Conduit
(ADO.NET
Classes)
Data
provider
Database
(SQL Server,
Access,
Oracle)
The data provider is the software that bridges the gap between the middle tier and the
data layer.
When we change data conduits to connect to a different database the data provider is
the key item of software being changed.
Connection Strings
When we create the connection object we must tell it (along with other things) what
data provider is to be used.
This information (along with other things) is handled by the connection string.
So for example the following code creates a connection to an Access database called
Address.mdb...
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\MyDb\Address.mdb"
Here we can see the data provider is Microsoft.Jet.OLEDB.4.0
The connection string may also contain additional data for connecting to the database
such as how security is applied.
Once an instance has been created of the connection object we may use the Open
method to create the connection.
//open the database
connectionToDB.Open();
The Command Object
Now that we have a connection to the database we need to think about how we apply
the changes to the database. The command object is used to send SQL to the database
either as an SQL statement or as a stored procedure.
In the case of this code we apply the stored procedure to the connection object like
so...
//initialise the command builder for this connection
OleDbCommand dataCommand = new OleDbCommand(SProcName, connectionToDB);
Once we have specified which stored procedure we intend to use and which database
we then need to add the parameters like so...
//loop through each parameter
for (int Counter = 0; Counter < SQLParams.Count; Counter += 1)
{
//add it to the command object
dataCommand.Parameters.Add(SQLParams[Counter]);
}
Once we have loaded up the command object with the parameters we then need to tell
it that we are running a stored procedure rather than raw SQL.
//set the command type as stored procedure
dataCommand.CommandType = CommandType.StoredProcedure;
We are now in the following position...
Database
(File or Server)
Class
Connection
Command object
(Stored procedure
name + parameters)
We have a connection established along with a command object poised to do
something to the database.
The Mincing Machine
To make sense of the next steps it is worth thinking about how a mincing machine
works...
Raw data
in the table
Connection
Command
When using a mincing machine we may think of the unprocessed meat as the raw
data. What we want is to take the meat through the machine (the connection) and
process it into mince (query results) by applying pressure to the on switch (the
command).
There are two additional items in this process that we need to model as classes.
We need a place for the data / mince to come out and we need something to catch the
data / mince in.
The Data Adapter
The data adapter may be thought of as the place where the data comes out of the
connection. Unlike a mincing machine we may also use the data adapter to send data
back along the connection. (Turning the mince into raw meat?)
The Data Table
The data table allows us to model and manipulate the data that comes out of the data
adapter.
So we may extend our mincing metaphor...
Data
adapter
Database
Connection
Data
Data Table
Command
Which in rather less mince related terms may be expressed as follows...
Program
Data
adapter
Database
(File or Server)
Connection
Data
Data table
Command object
(Stored procedure
name + parameters)
Initialising the Data Adapter
For the data adapter to do its job we need to tell it which command it is responding to
by setting the SelectCommand property...
//set the select command property for the data adapter
dataChannel.SelectCommand = dataCommand;
Once it knows what it has to do we then tell it to do it...
//fill the data adapter
dataChannel.Fill(queryResults);
Notice that the Fill method accepts one parameter.
In this case queryResults is an instance of the DataTable class.
The data adapter applies the command in the command object (our stored procedure)
and the resulting records are stored in the data table queryResults.
Data Tables
Once the data adapter has done its job we typically get some data back from the
database. If it is the result of a select query it will be a sub set of records from one or
more tables.
So consider the following table...
We apply the following SQL as our command...
Select * from tblAddress
Obtaining all of the records in the table.
The command is applied to the data adapter and the data table is populated with our
data.
A data table is constructed of zero or many indexed data row objects.
To reference “Nottingham” in our code we would do the following...
AnAddress.Town = queryResults.Rows[3]["Town"].ToString();
Data Readers
Now that we have looked at the main classes for ADO.NET we will take a brief look
at an additional class we are not covering in the module the data reader.
The DataReader may be used to retrieve a read-only, forward-only stream of data
from a database.
Data readers are much faster than data tables however the data cannot be written to
and we cannot go backwards through the data. The data reader also locks the
underlying data while it is processing it. This means we must remember to close the
data reader when we are done with it and it can also create problems if we want to
open more than one connection on the data at the same time.
Below is some sample code that illustrates how a data reader may be used...