Home                      About Us                      Products                      News                      Partners                      Support
Product Quick Links
mv.NET

Related Products
 
More Information
  Product Documentation
  Online Demonstrations

 

Connections
Connections are used to 'talk to' databases, and are represented by provider-specific classes such as mvConnection in the case of mv.NET.   Connections can be opened explicitly by calling the Open method of the connection, or will be opened implicitly when using a DataAdapter 

Commands
Commands contain the information that is submitted to a database, and are represented by provider-specific classes such as mvCommand.  A command can be a stored procedure call, an database DML statement, or a statement that returns results.  You can also use input and output parameters, and return values as part of your command syntax.  Commands travel over connections and resultsets are returned in the form of streams which can be read by a DataReader object, or pushed into a DataSet object. 

DataReaders
The DataReader object is somewhat synonymous with a traditional read-only/forward-only cursor over data. The DataReader API supports flat as well as hierarchical data.  A DataReader object is returned after executing a command against a database.

DataSets
 The DataSet object represents a cache of data, with database-like structures such as tables, columns, relationships, and constraints. However, though a DataSet can and does behave much like a database, it is important to remember that DataSet objects do not interact directly with databases, or other source data. This allows the developer to work with a programming model that is always consistent, regardless of where the source data resides.   

DataAdapters
The DataAdapter object works as a bridge between the DataSet and the source of data, pulling data into the DataSet, and reconciling (pushing) data back into the database.  The DataAdapter object uses commands to update the data source after changes have been made to the DataSet.  Using the 'Fill' method of the DataAdapter calls the SELECT command; using the 'Update' method calls the INSERT, UPDATE or DELETE command for each changed row.  You can explicitly set these commands in order to control the statements used at runtime to resolve changes, including the use of stored procedures.  

 

Click here for further information on the ADO.NET architecture

 

What is ADO.NET?
 

ADO.NET is the standard method by which .NET developers are able to interact with databases.  It comprises a large suite of class definitions which, collectively, provide a rich environment for database access and manipulation.   

ADO.NET has a relatively complex architecture and it is beyond the scope of this manual to document all aspects of this technology.  However, below is a diagram which summarizes the way in which ADO.NET's architecture is constructed.

ADO.NET is an evolution of Microsoft’s previous ADO data access model. ADO.NET uses some previous ADO class names, such as the Connection and Command, but also introduces many new classes, the key ones being the DataSet, DataReader, and DataAdapter.  

The key difference between ADO.NET and previous Microsoft data architectures is the existence of the 'DataSet' class, which introduces the concept of a separate and distinct level of data repository from any data store (database).  Because of this, the DataSet functions as a standalone entity and may, thus, be regarded as an always disconnected recordset with no knowledge of the source or destination of the data it contains. 

The DataSet is comprised of entities which mimic the traditional database paradigm, containing such things as tables, columns, relationships, constraints and views.   

A key concept within ADO.NET is that of the 'DataAdapter' class connecting to the database in order to fill the DataSet with data.  Upon data update, it can then connect back to the database in order to persist the updates.  

Historically, data maintenance has been primarily connection-based.  However, in an attempt to make multi-tiered apps more efficient, data processing is favoring a message-based approach revolving around the exchange of chunks of information.  

The DataAdapter lies at the heart of this approach, providing a bridge to retrieve and save data between a DataSet and its source data store.  It accomplishes this by the use of various 'Command' objects, each of which being configured by the developer to contain the requisite database manipulation commands in order to interact with the data store in the desired manner.  

The DataSet is engineered heavily around the storage of data in XML format, providing a consistent programming model able to work with broad range of data storage products: flat, relational, and hierarchical.  It does this by not recording any information relating to the source of its data, and by representing the data that it holds as collections and data types.  Irrespective of the actual source of the data within the DataSet, its contents are manipulated through the same set of standard APIs exposed through the DataSet and its subordinate objects.  

While the DataSet has no knowledge of the source of its data, ADO.NET revolves around the concept of a 'managed data provider', which, conversely, has very detailed and specific information relating to the data source.  The role of the managed data provider is to connect, fill, and persist the DataSet content to and from data stores.  The concept of a managed data provider manifests itself as a series of interfaces; these interfaces need to be implemented by a developer in order to provide the database specific logic which ultimately allows the database neutral functionality of the DataSet to be connected to a specific data store in order to provide data persistence. 

Thus, in summary, ADO.NET consists of the following conceptual objects, the implementation of which is provided partly generically by the .NET framework and partly by the database vendor/integrator.