Entry for December 10, 2006
Disconnected Architecture: ADO.Net
ADO.Net is an interest subject. Till a few days ago I thought that ADO meant 'access database object'; but I was wrong. It means ActiveX Database Object. And the .net version of this is something that supports the .net framework. There are many things about this database object. First of all ado is an object model. In simpler terms, an object model is something (usually a documentation) that exposes the structural realtionships between various components of a library object. The main purpose of this is to allow someone to figure out how to work with the object in a program. Common examples of object models (OMs) are the MS Word DOM, XML DOM, etc.
While learining the features about ado.net I heard the term called disconnected architecture. On understanding what it was, I understood that there is a middle man between a database and an application that uses that particular database. In .net terminology this is called the data provider. The data provider provides services that operate on a database. Operation could mean anything from reading to updating a particular record or deletion. The middle man here tries to make our job easier for us if we decide to connect to a database. Howevr, like usual, we need to connect to a database (i.e. establish a connection) and then retrieve/update data.
Earlier once that database is connected to a program it is bound to the execution life of that program. Until and unless the user disconnects the database from the application the database is locked for that application. No other program can access that database. But in ado.net, all the info that is there in the database get stored into something called a dataset. So the application interacts with the dataset; not the database.
The transfer of information from the database to the dataset is done through XML. However the user/programmer need not know about this. We can do updates on the dataset. We just have to execute a command to update the database from the application. Once that is done the data provider takes the role of ensuring that the updation is carried out. Again xml comes into fcous here.
So as you can see. We are not directly interacting with the database. This is what the disconnected architecture is all about. But the one thing I immediately realised and thought of sharing is that the database is not locked to the application. Thus the database can be used by multiple applications.
I am now going to conclude this post but this does not mean that the ado.net only provides for a disconnected architecture. It also has a mechanism that uses the connected architecture. Do not forget that...