ADO.

NET
Dr.Khaled ElBahnasy

What Is ADO.NET?
ADO.NET is a family of technologies that allows .NET developers to interact with data in standard, structured, and primarily disconnected ways. Applications written using the .NET Framework depend on .NET class libraries, which exist in special DLL files that encapsulate common programming functionality in an easy-to-access format. Most of the libraries supplied with the .NET Framework appear within the System namespace. System.IO, for instance, includes classes that let you interact with standard disk files and related data streams. The System.Security library provides access to, among other things, data encryption features.

What Is ADO.NET?
ADO.NET, expressed through the System.Data namespace, implements a small set of libraries that makes consuming and manipulating large amounts of data simple and straightforward. ADO.NET manages both internal datadata created in memory and used solely within an applicationand external datadata housed in a storage area apart from the application, such as in a relational database or text file. Regardless of the source, ADO.NET generalizes the relevant data and presents it to your code in spreadsheet style rows and columns.

What Is ADO.NET?
Although ADO.NET manipulates data in tabular form, you can also use ADO.NET to access nontabular data. For instance, an ADO.NET provider could supply access to hierarchical data such as that found in the Windows Registry, as long as that provider expressed the data in a tabular structure for ADO.NETs use.

What Is ADO.NET?
If you are already familiar with relational databases such as Microsoft SQL Server, you will encounter many familiar terms in ADO.NET. Tables, rows, columns, relations, views; these ADO.NET concepts are based loosely on their relational database counterparts. Despite these similarities, ADO.NET is not a relational database because it doesnt include key relational algebra features typically found in robust database systems. It also lacks many of the common support features of such databases, including indexes, stored procedures, and triggers. Still, if you limit yourself to basic create, read, update, and delete (CRUD) operations, ADO.NET can act like a miniature yet powerful in-memory database.

What Is ADO.NET?
As an acronym, ADO.NET stands fornothing. Just like the words scuba, laser, and NT in Windows NT, the capital letters in ADO.NET used to mean something, but now it is just a standalone term. Before Microsoft released the .NET Framework, one of the primary data access tools Windows developers used in their programs was known as ADO, which did stand for something: ActiveX Data Objects. After .NET arrived on the scene, ADO.NET became the natural successor to ADO. Although conceptual parallels exist between ADO.NET and ADO, the technologies are distinct and incompatible.

Note
ADO is based on Microsofts older COM technology. The .NET Framework provides support for COM components, and therefore enables .NET programs to use ADO. This is especially useful for development teams transitioning legacy applications to .NET. Although ADO and ADO.NET components can appear in the same application, they can interact only indirectly because their object libraries are unrelated.

What Is ADO.NET?
When communicating with external data stores, ADO.NET presents a disconnected data experience. In earlier data platforms, including ADO, software developers would typically establish a persistent connection with a database and use various forms of record locking to manage safe and accurate data updates. But then along came the Internet and its browsercentric view of information. Maintaining a long-standing data connection through bursts of HTTP text content was no longer a realistic expectation. ADO.NETs preference toward on-again, off-again database connections reflects this reality.

What Is ADO.NET?
Although this paradigm change brought with it difficulties for traditional client-server application developers, it also helped usher in the era of massive scalability and n-tier development that is now common to both desktop and Web-based systems.

Why ADO.NET?
In the early days of computer programming, the need for a data library like ADO.NET didnt exist. Programmers had only a single method of accessing data: direct interaction with the values in memory. Permanently stored data existed on tape reels in fire-resistant, climatecontrolled, raised-floor rooms. Data queries could take hours, especially if someone with more clout had a higher-priority processing need.

Why ADO.NET?
Over time, computers increased in complexity, and (as if to fill some eternal maxim) data processing needs also expanded to consume all available computing resources. Businesses sought easier ways to manage entire records of numeric, text, and date-time values on their mainframe systems. Flat-file and relational database systems sprang up to establish proprietary management of millions of data values. As personal computers arrived and matured, developers soon had several database systems at their disposal.

Why ADO.NET?
This was great news for data consumers. Businesses and individuals now had powerful tools to transform data bits into usable information, to endow seemingly unrelated values with meaning and purpose. But it was bad news for developers. As technology marched on, companies purchased one proprietary system after another. Programming against such systems meant a reinvention of the proverbial wheel each time a middle manager asked for yet another one-time report. Even the standard SQL language brought little relief because each database vendor provided its own spin on the meaning of standard.

Why ADO.NET?
What programmers needed was a way to generalize different data systems in a standard, consistent, and powerful way. In the world of .NET application development, Microsoft ADO.NET meets that need. Instead of worrying about the minutiae associated with the different database systems, programmers using ADO.NET focus on the data content itself.

Major Components of ADO.NET

Major Components of ADO.NET

At the data-shaped heart of the library is the DataTable. Similar in purpose to tables in a database, the DataTable manages all the actual data values that you and your source code ultimately care about. Each DataTable contains zero or more rows of data, with the individual data values of each row identified by the tables column definitions. Each table defines DataColumn items, each representing the individual data values that appear in the tables records. DataColumn definitions include a data type declaration based on the kind of data destined for each column. For instance, a CustomerLastName column might be defined to use data of type System.String, whereas an OrderSalesTax column could be crafted for use with System.Decimal content. One DataRow entry exists for each record of data stored within a table, providing access to the distinct columnar data values. ADO.NET includes methods that let you add to, delete from, modify, and query each DataTable objects rows. For tables connected to an external data storage area, any changes made can be propagated back to the source. You can optionally establish links between the tables of data using DataRelation entries.

Programmatic limitations can be placed on tables and their data values using Constraint instances. DataView instances provide a limited or modified view of the rows in a DataTable. Tables can be grouped together into a DataSet. Some tools that interact with ADO.NET data require that any tables be bound within a DataSet, but if you plan to do some limited work with only a single table, its fine to work with just the DataTable instance. DataTable instances and their associated objects are sufficient for working with internal data. To connect with external data from a database, ADO.NET features multiple data providers, including a custom provider for Microsoft SQL Server. Database platforms without a specific provider use the more generic ODBC and OLE DB providers, both included with ADO.NET. Several third-party providers can be purchased or obtained free of charge, which target specific platforms, including Oracle. All communication with the external data source occurs through a Connection object. ADO.NET supports connection pooling for increased efficiency between queries. SQL queries and data management statements get wrapped in a Command object before being sent to the data source. Commands can include optional Parameter instances that let you call stored procedures or create fill-in-the-blank queries. The DataAdapter object stores standard query definitions for interacting with a database, removing the tedium of constantly needing to build SQL statements for each record you want to read or write, and helping to automate some ADO.NET-related tasks. The DataReader object provides fast, read-only access to the results of a query for those times when you just need to get your data quickly. ADO.NET also includes features that let you save an entire DataSet as an XML file and load it back in later. And thats just the start. Youll learn how to use all these elementsand more throughout the upcoming chapters.

 Extensions to ADO.NET Generalizing access to data is a key benefit of using ADO.NET. But an even greater advantage for .NET developers is that all values managed through ADO.NET appear as objects, first-class members of the .NET data world. Each data field in a table is a strongly typed data member, fully compliant with .NETs Common Type System. Individual fields can be used just like any other local variable. Data rows and other sets of objects are standard .NET collections and can be processed using standard iteration methods.

Because ADO.NET values exist as true .NET objects and collections, Microsoft has enhanced the core ADO.NET feature set with new tools. Two of these technologies, the Entity Framework and LINQ, are not formally part of ADO.NET. But their capability to interact with and enhance the ADO.NET experience makes them essential topics for study. The Entity Framework, the focus of Part III of this book, emphasizes the conceptual view of your data. Although the data classes in ADO.NET are programmer-friendly, you still need to keep track of primary keys and relationships between tables and fields. The Entity Framework attempts to hide that messiness, and restores the promise of what object-oriented programming was supposed to be all about. In the Entity Framework, a customer object includes its orders; each order includes line item details. Instead of working with the raw table data, you interact with logically designed entities that mimic their real-world counterparts, and let the Framework worry about translating it all into SQL statements. LINQ, introduced in Part IV, brings the joy of English-like queries to your favorite programming language. Microsoft enhanced both Visual Basic and C# with new LINQ-specific language features. Now, instead of building string-based SQL statements to query data, the syntax of each programming language becomes the query language. LINQ is a generic data tool, enabling you to easily mix ADO.NET data and other content sources together into a single set of results.

 Connecting to External Data Chapter 8, Establishing External Connections, introduces the code elements that support communications between ADO.NET and external sources of data. Although using only code to establish these connections is quite common, Visual Studio also includes the Data Source Connection Wizard, a mouse-friendly tool that guides you through the creation of a readyto use DataSet. Heres an example of using the Connection Wizard.