ADO.NET
  Home arrow ADO.NET arrow Page 2 - All You Need To Know About ADO.NET: Part 2...
IBM developerWorks
Dev Articles Forums 
ADO.NET  
Apache  
ASP  
ASP.NET  
C#  
C++  
ColdFusion  
COM/COM+  
Delphi-Kylix  
Design Usability  
Development Cycles  
DHTML  
Embedded Tools  
Flash  
Graphic Design  
HTML  
IIS  
Interviews  
Java  
JavaScript  
MySQL  
Oracle  
Photoshop  
PHP  
Reviews  
Ruby-on-Rails  
SQL  
SQL Server  
Style Sheets  
VB.Net  
Visual Basic  
Web Authoring  
Web Services  
Web Standards  
XML  
Dedicated Servers  
Actuate Whitepapers 
Moblin 
IBM® developerWorks 
Sun Developer Network 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
IBM developerWorks
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ADO.NET

All You Need To Know About ADO.NET: Part 2/2
By: Vaijayantee Sateesh Kamat
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 38
    2002-04-15

    Table of Contents:
  • All You Need To Know About ADO.NET: Part 2/2
  • ADO.NET's Disconnected Architecture
  • Building An In-Memory Schema
  • DataRelation Objects and Constraints
  • Examining the XSD
  • Conclusion

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT

    Stay one step ahead of the competition. Evaluate and give feedback on some of the hottest web development tools on the market today. Make your opinion heard! Click Here

    All You Need To Know About ADO.NET: Part 2/2 - ADO.NET's Disconnected Architecture


    (Page 2 of 6 )

    We have been continuously stressing that ADO.NET uses a disconnected
    architecture. With the ever-increasing demand on the Web, data requirements are changing. Now, scalability has become a major issue thanks to the ever growing population of the web. Another aspect is availability of an open connection for the data all of the time. Both these issues require that applications should connect to the data source, read required data and disconnect the connection, process the data, reconnect and save the changes. Using disconnected RecordSets is tedious with ADO due to marshalling issues. All this was leading to disconnected architecture for quite some time now.

    It was but natural that Microsoft would introduce this architecture in the latest version of ADO, which is ADO.NET. We have just seen how to use a Connection object, a Command object and a DataReader to perform database operations. This is good enough when you want to process only one row at a time. In practice however, one needs to process or display multiple rows at a time. In such cases, it is difficult to use the DataReader. Therefore, ADO.NET provides other objects for such operations. These objects are mostly use in a disconnected environment.

    The DataAdapter Object
    Data adapters are an integral part of the ADO.NET managed providers. They are the set of objects used to communicate between a data source and a DataSet. Adapters are used to exchange data between a data source and a DataSet. Mostly, this would mean reading data from a database into a DataSet, and then writing changed data from the DataSet back to the database. The DataAdapter, however, is more capable. It can move data between any source and a DataSet. For example, there could be an adapter that moves data between a Microsoft Exchange server and a DataSet.

    Generally, we can configure the DataAdapter so that we can specify what data to move into and out of the DataSet. Often this takes the form of references to SQL statements or stored procedures that are invoked to read or write to a database. ADO.NET has two primary data adapters for use with databases:
    • The OleDbDataAdapter: This object is suitable for use with any data source exposed by an OLEDB provider.
    • The SqlDataAdapter: The SQLDataAdapter object is specific to SQL Server. Because it does not have to go through an OLEDB layer, it is faster than the OleDbDataAdapter. However, it can only be used with SQL Server 7.0 or later.
    This means that vendors can create vendor specific DataAdapters that can be faster or more efficient for different types of data sources. Normally, one DataAdapter is created for one table or data set. If the DataSet consists of more than one table, usually a separate DataAdapter is created for each table. For populating a DataSet, a DataAdapter's Fill method is called. For writing the updated data back to the table, the DataAdapter's update method is called. A DataAdapter is created by the DataAdapter configuration wizard or by using the server explorer. A DataAdapter can also be configured manually by using the property window.

    The DataSet Object
    The DataSet object can be thought of as the heart of ADO.NET's disconnected architecture. The DataSet object is an in memory copy of the data stored by a DataAdapter. The structure of the DataSet is like a relational database. It exposes a hierarchical model of tables, rows and columns. It also contains constraints and relations just like a database. When working with a set of related tables, the DataSet becomes a handy object.

    Another important feature of the DataSet is that it uses XML to represent the data.
    The structure of the DataSet, its tables, rows, columns, and everything else can be defined as an XML schema. A DataSet can read and write XML schemas using its ReadXmlSchema and WriteXmlSchema methods. XML is used to store and transmit data of all kinds. As XML is an almost universally accepted format, the data can be transported to or received from any platform using a DataSet.

    The DataSet is populated with:
    • A DataAdapter's Fill method
    • Using the ReadXml method
    • Manually
    The DataSet is not connected to a data source after it is populated. This feature differentiates it from ADO objects. An ADO RecordSet has record pointers while all the records are current in a DataSet. That's why it does not support record navigation methods. Instead of using a record, the DataSet object uses the Rows collection. It can still be manipulated like any collection, however. AS the DataSet is an in-memory database, ADO.NET provides us with methods to build the schema for the DataSet easily.

    More ADO.NET Articles
    More By Vaijayantee Sateesh Kamat


     

    ADO.NET ARTICLES

    - Datasets in Microsoft.Net
    - Latest Developments in the .Net World
    - Introduction to .NET
    - Automatic Generation of Single Table SQL Sta...
    - Data Access in .NET using C#: Part 1
    - All You Need To Know About ADO.NET: Part 2/2
    - All You Need To Know About ADO.NET: Part 1/2
    - Easing Transition From ASP and ADO to ASP.NE...
    - A Practical Comparison of ADO and ADO.NET







    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 1 hosted by Hostway