Database_C# - 4193ch22.qxd 8/14/05 3:03 PM Page 759 CHAPTER...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
U nless you are a video game developer by trade, you are probably interested in the topic of data- base access. As you would expect, the .NET platform defines a number of namespaces that allow you to interact with local and remote data stores. Collectively speaking, these namespaces are known as ADO.NET . In this chapter, once I frame the overall role of ADO.NET (in the next section), I’ll move on to discuss the topic of ADO.NET data providers. The .NET platform supports numerous data providers, each of which is optimized to communicate with a specific database management system (Microsoft SQL Server, Oracle, MySQL, etc.). After you understand how to manipulate a specific data provider, you will then examine the new data provider factory pattern offered by .NET 2.0. Using types within the System.Data.Common namespace (and a related app.config file), you are able to build a single code base that can dynamically pick and choose the underlying data provider without the need to recompile or redeploy the application’s code base. The remaining part of this chapter examines how to programmatically interact with relational databases using your data provider of choice. As you will see, ADO.NET provides two distinct ways to interface with a data source, often termed the connected layer and disconnected layer . You will come to know the role of connection objects, command objects, data readers, data adapters, and numerous types within the System.Data namespace (specifically, DataSet , DataTable , DataRow , DataColumn , DataView , and DataRelation ). A High-Level Definition of ADO.NET If you have a background in Microsoft’s previous COM-based data access model (Active Data Objects, or ADO), understand that ADO.NET has very little to do with ADO beyond the letters “A,” “D,” and “O.” While it is true that there is some relationship between the two systems (e.g., each has the con- cept of connection and command objects), some familiar ADO types (e.g., the Recordset ) no longer exist. Furthermore, there are a number of new ADO.NET types that have no direct equivalent under classic ADO (e.g., the data adapter). Unlike classic ADO, which was primarily designed for tightly coupled client/server systems, ADO.NET was built with the disconnected world in mind, using DataSet s. This type represents a local copy of any number of related tables. Using the DataSet , the client tier is able to manipulate and update its contents while disconnected from the data source, and it can submit the modified data back for processing using a related data adapter. Another major difference between classic ADO and ADO.NET is that ADO.NET has deep support for XML data representation. In fact, the data obtained from a data store is serialized (by default) as XML. Given that XML is often transported between layers using standard HTTP, ADO.NET is not limited by firewall constraints. 759
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 02/07/2011 for the course PHYS 101 taught by Professor Aster during the Spring '11 term at East Tennessee State University.

Page1 / 68

Database_C# - 4193ch22.qxd 8/14/05 3:03 PM Page 759 CHAPTER...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online