ADO.NET
  Home arrow ADO.NET arrow All You Need To Know About ADO.NET: Part 1...
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  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 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 1/2
By: Vaijayantee Sateesh Kamat
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 89
    2002-04-14

    Table of Contents:
  • All You Need To Know About ADO.NET: Part 1/2
  • Data binding in Windows application
  • Binding Controls to Data Sources
  • Creating a master/detail app
  • 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


    All You Need To Know About ADO.NET: Part 1/2


    (Page 1 of 5 )

    Fundamentally, almost all business applications need some type of access to data stored in a database. They need access to this data quickly, and in a number of different formats. This is where ADO.NET comes into the picture. In this series of two articles, Vaijayantee explains exactly what ADO.NET is, including discussions on scalability, architecture, etc. She also shows us how to use ADO.NET with VB.NET and Visual Studio.NET.Fundamentally, almost all business applications need some type of access to data. In addition, many a time, business components need to interact with each other using XML and XML based Internet services. This is where ADO.NET comes into picture.

    Microsoft has provided us with several high level data access API's.

    The data access method called Data Access Objects or more popularly known as DAO was primarily intended for jet databases and was optimized for it although it could be used for ODBC based data sources.

    In order to deal with server based databases more efficiently, Microsoft built a wrapper on top of ODBC. It was called Remote Data Objects (RDO), and it provided an object model similar to DAO. Unfortunately, as the objects could not be marshalled across the net, it was of limited use.

    DAO and RDO both used the API approach for accessing data. Microsoft wanted to use a COM based approach to data access, and the result was OleDB and ADO. ADO is the OLE automation implementation built on top of OleDB. ADO was first introduced with the first version of ASP. The primary advantage with ADO was improved support for disconnected data and the ability for a disconnected recordset to marshall over the network.

    Microsoft decided to create a database access model to go with the .NET Framework. It mainly focuses on the following key goals:
    • XML integration
    • Disconnected data model
    • Scalability
    [NOTE] Although similar in concept, ADO.NET has different functionality from ADO. Experienced VB programmers will find that more often than not, they will not be using the recordets they are familiar with. ADO.NET introduces quite a few objects used for data access in various manners and conditions. [End Note]

    ADO.NET is broken down into 3 namespaces in the .NET framework. Namespaces are used to organize components into groups based on organizational and logical reasons.



    In previous versions of ADO, an attempt was made to create as generic methods as possible, whereas with ADO.NET, the data provider classes for SQL server are now optimized. Optimized data providers for specific database products can now be created also.

    From a developers point of view, objects provided by OleDB managed providers and SQL server managed providers are quite similar, the only difference being they are prefixed with SQL rather than OleDB.

    Let's now see how to use ADO.NET in an application. We will use the Pubs sample database that is included with SQL server 2000. We will use the Authors, Publishers, Titles and TitleAuthor tables. Although we will use OleDB managed providers, the same code can be used for SQL managed providers very easily. You can even use access tables in place of SQL tables if you do not have SQL tables.

    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-2009 by Developer Shed. All rights reserved. DS Cluster 2 Hosted by Hostway
    Stay green...Green IT