ADO.NET introduction
Most applications require some kind of data access. Desktop applications need to integrate with central databases, Extensible Markup Language (XML) data stores, or local desktop databases. ADO.NET data access technology allows simple, powerful data access while maximizing system resource usage.
Different applications have different requirements for data access. Whether your application simply displays the contents of a table or processes and updates data to a central SQL server, ADO.NET provides the tools to implement data access easily and efficiently.
Disconnected Database Access
Previous versions of data access technologies have provided continuously connected data access by default. In such a model, an application creates a connection to a database and keeps it open for the life of the application or at least for the amount of time that data is required. As applications become more complex and databases begin to serve more and more clients, a connected data access technology becomes impractical for a variety of reasons.
For example:
Open database connections are expensive in terms of system resources. The more open connections, the less efficient system performance becomes.
Applications with connected data access are very difficult to scale up. An application that can maintain connections with two clients might do poorly with 10, and might be completely unusable with 100.
ADO.NET addresses these issues by implementing a disconnected database access model by default. In this model, data connections are established and only left open long enough to perform the requisite action. For example, if data is being requested from a database by an application, the connection is opened just long enough to load the data into the application, and then it is closed.
Likewise, if a database is being updated, the connection is opened to execute the UPDATE command, and then closed again. By keeping connections open only for the minimum required time, ADO.NET conserves system resources and allows data access to be scaled up with a minimal impact on performance.
ADO.NET Data Architecture
Data access in ADO.NET relies on two components: the DataSet, which stores data on the local machine, and the Data Provider, which mediates interaction between the program and the database.
The DataSet
The DataSet is a disconnected, in-memory representation of data. It can be thought of as a local copy of the relevant portions of the database. Data can be loaded into a DataSet from any valid data source, such as a Microsoft SQL Server database, a Microsoft Access database, or an XML file.
The DataSet is persisted in memory, and the data therein can be manipulated and updated independent of the database. When appropriate, the DataSet can then act as a template for updating the central database.
The DataSet object contains a collection of zero or more DataTable objects, each of which is an in-memory representation of a single table. The structure of a particular DataTable is defined by the DataColumns collection, which enumerates the columns in a particular table, and the Constraint Collection, which enumerates the constraints on the table.
Together, these two collections make up the schema of the table. A DataTable also contains a DataRows collection, which contains the actual data in the DataSet.
The DataSet contains a DataRelations collection. A DataRelation object allows you to create associations between rows in one table and rows in another table. The DataRelations collection enumerates a set of DataRelation objects that defines these relationships between tables in the DataSet.
For example, consider a DataSet that contains two related tables: a Customers table and an Orders table. In the Customers table, each customer is represented only once and is identified by a CustomerID field that is unique. In the Orders table, the customer who placed the order is identified by the CustomerID field, but can appear more than once if a customer has placed multiple orders. This is an example of a one-to-many relationship, and you would use a DataRelation object to define that relationship.
Additionally, a DataSet contains an ExtendedProperties collection, which is used to store custom information about the DataSet.
The Data Provider
The link to the database is created and maintained by the Data Provider. A Data Provider is not actually a single component, but a set of related components that work together to provide data in an efficient, performance-driven manner. The Microsoft .NET Framework currently ships with two data providers: the SQL Server .NET Data Provider, which is designed specifically to work with Microsoft SQL Server 7.0 or later, and the OleDb .NET Data Provider, which connects with other types of databases. Each Data Provider consists of similar versions of the following generic component classes:
The Connection object provides the connection to the database.
The Command object is used to execute a command against a data source. It can execute either non-query commands, such as INSERT, UPDATE, or DELETE, or return a DataReader with the results of a SELECT command.
The DataReader object provides a forward-only, read-only, connected recordset.
The DataAdapter object populates a disconnected DataSet or DataTable with data and performs updates.
Data access in ADO.NET is facilitated as follows: A Connection object establishes a connection between the application and the database. This connection can be accessed directly by a Command object or by a DataAdapter object.
The Command object provides direct execution of a command to the database. If the command returns more than a single value, the Command object returns a DataReader to provide the data. This data can be directly processed by application logic. Alternatively, you can use the DataAdapter to fill a DataSet object. Updates to the database can be achieved either through the Command object or through the DataAdapter.
The generic classes that make up the Data Providers are summarized in the following sections.
The Connection Object
The Connection object represents the actual connection to the database. Microsoft Visual Studio .NET provides two types of Connection classes: the SqlConnection object, which is designed specifically to connect to Microsoft SQL Server 7.0 or later, and the OleDbConnection object, which can provide connections to a wide range of database types. The Connection object contains all of the information required to open a channel to the database in the ConnectionString property. The Connection object also provides methods that facilitate data transactions.
The Command Object
The Command object is also represented by two corresponding classes: SqlCommand and OleDbCommand. You can use the Command objects to execute commands to a database across a data connection. The Command objects can be used to execute stored procedures on the database, execute SQL commands, or return complete tables directly. Command objects provide three methods that are used to execute commands on the database:
ExecuteNonQuery.
Executes commands that have no return values, such as INSERT, UPDATE, or DELETE.
ExecuteScalar.
Returns a single value from a database query.
ExecuteReader.
Returns a result set by way of a DataReader object.
The DataReader Object
The DataReader object provides a forward-only, read-only, connected stream recordset from a database. Unlike other components of the Data Provider, DataReader objects cannot be directly instantiated. Rather, the DataReader is returned as the result of a Command object's ExecuteReader method.
The SqlCommand.ExecuteReader method returns a SqlDataReader object, and the OleDbCommand.ExecuteReader method returns an OleDbDataReader object. The DataReader can provide rows of data directly to application logic when you do not need to keep the data cached in memory. Because only one row is in memory at a time, the DataReader provides the lowest overhead in terms of system performance, but requires the exclusive use of an open Connection object for the lifetime of the DataReader.
The DataAdapter Object
The DataAdapter is the class at the core of ADO.NET's disconnected data access. It is essentially the middleman, facilitating all communication between the database and a DataSet. The DataAdapter fills a DataTable or DataSet with data from the database when the Fill method is called. After the memory-resident data has been manipulated, the DataAdapter can transmit changes to the database by calling the Update method. The DataAdapter provides four properties that represent database commands:
SelectCommand.
Contains the command text or object that selects the data from the database. This command is executed when the Fill method is called, and fills a DataTable or a DataSet.
InsertCommand.
Contains the command text or object that inserts a row into a table.
DeleteCommand.
Contains the command text or object that deletes a row from a table.
UpdateCommand.
Contains the command text or object that updates the values of a database.
When the Update method is called, changes in the DataSet are copied back to the database, and the appropriate InsertCommand, DeleteCommand, or UpdateCommand is executed.
Filtering Data
Binding, Viewing, and Filtering Data
Viewing data is a vital part of many applications. Data binding allows you to associate records in a data source with controls on a form, allowing them to be browsed and updated. In this lesson, you will learn how to use ADO.NET to bind data to controls in your application and how to manage currency of records in your application.
Data binding refers to a relationship between a data provider and a data consumer. A data provider is a source for data and is linked to a data consumer, which receives data and processes or displays it.
A traditional example of data binding is the relationship between a data-bound control such as a TextBox and a data source. The control displays the value of the column in the data source to which it is bound at the current row. As the current row changes, the value displayed by the control changes.
Data Providers
In the .NET Framework, any object that implements the IList interface can be a data provider. This not only includes ADO.NET objects, such as DataSets, DataTables, and DataColumns, but also more mundane objects such as arrays or collections. DataViews, which are discussed later in this lesson, are a customizable view of data that can also act as a data provider.
Data providers also manage currency of data. In previous data access technologies, a cursor was used to manage data currency. As the cursor moved, the current record changed and bound controls were updated. Because data access in ADO.NET is fundamentally disconnected, there is no concept of a database cursor. Rather, each data source has an associated CurrencyManager object that keeps track of the current record. CurrencyManager objects are managed through a form's BindingContext object. Data currency is discussed in detail later in this lesson.
Data Consumers
The data consumer represents the control with bound properties. In the .NET Framework, you can bind any run-time accessible property of any control to a data source. For example, you could bind the Size property of a control to a database record, or the location, or any other run-time accessible property of the control.
Data binding has a wide variety of uses. A typical scenario that involves data binding is a data entry form. Several controls, such as TextBox, CheckBox, ListBox, and so on are bound to relevant columns of a DataSet. New records are manually entered by typing values for each column into the appropriate controls displayed on the form. When a record is complete, it is added to the DataSet, which can then be used to update the database.
There are two types of data binding: simple binding and complex binding. A simple-bound control binds one record at a time to a control. For example, a Label control can be simply bound to a column in a DataTable. In such a case, it would display the member of that column for the current record.
Complex binding, on the other hand, allows multiple records to be bound to a single control. Controls such as ListBox or ComboBox can be complex bound to a single column in a DataTable or DataView. At run time, these controls would display all members of that column rather than only the current row. Complex-bound controls are usually involved in displaying choices and allowing specific rows of data to be chosen. Controls such as the DataGrid are capable of even more complex binding and can be bound to all column and rows of a particular DataTable or DataView, or even to a DataSet.
Creating a Simple-Bound Control
You can create a simple-bound control through the DataBindings property. The DataBindings property is an instance of the ControlBindingsCollection class that keeps track of and organizes which controls are bound to what data sources. At design time, the DataBindings property is displayed as a node in the Properties window. This node expands to list the properties that are most commonly data bound.
Data Binding at Run Time
You might want to change the data source that a control is bound to at run time. Or, you might not know at design time what data source a particular control might be bound to. In a third scenario, you might want to bind your control to an array or collection that is not instantiated until run time, in which case, you must set the binding in code.
Data binding for a control is managed through the control's DataBindings property, which is an instance of a ControlBindingsCollection object. At run time, you can add, remove, or clear data binding information by setting the appropriate member of the DataBindings collection.
You can bind a property to a data source by using the DataBindings.Add method. This creates a new binding association and adds it to the DataBindings collection. The Add method takes three parameters: the property name you want to bind, as a String; the data source you want to bind to, as an object; and the data member of the data source you want to bind the property to.
The CurrencyManager
The CurrencyManager object keeps track of the current record for a particular data source. There can be multiple data sources in an application at one time, and each data source maintains its own CurrencyManager. Because there can be multiple data sources represented on a single form at any given time, each form manages the CurrencyManager objects associated with those data sources through a central object called the BindingContext.
The BindingContext organizes and exposes the CurrencyManager objects associated with each data source. Thus, you can use the BindingContext property of each form to manage the position of the current record for each data source. You access a particular currency manager by supplying the BindingContext property with the data source object whose CurrencyManager you want to retrieve.
To navigate bound data in a Windows Form
Set the Position property for the appropriate BindingContext member.
Because the .NET Framework will not allow you to set the Position property to a value less than zero or greater than the upper bound of the collection, there is no possibility of an error occurring if you attempt to move before or after the end of the records.
You might, however, want to incorporate program logic to provide visual cues to users to let them know when the end or beginning of a group of records is reached. The following example demonstrates how to use the PositionChanged event of the CurrencyManager to disable back and forward buttons when the end of the record list is reached.
Viewing data is a vital part of many applications. Data binding allows you to associate records in a data source with controls on a form, allowing them to be browsed and updated. In this lesson, you will learn how to use ADO.NET to bind data to controls in your application and how to manage currency of records in your application.
Data binding refers to a relationship between a data provider and a data consumer. A data provider is a source for data and is linked to a data consumer, which receives data and processes or displays it.
A traditional example of data binding is the relationship between a data-bound control such as a TextBox and a data source. The control displays the value of the column in the data source to which it is bound at the current row. As the current row changes, the value displayed by the control changes.
Data Providers
In the .NET Framework, any object that implements the IList interface can be a data provider. This not only includes ADO.NET objects, such as DataSets, DataTables, and DataColumns, but also more mundane objects such as arrays or collections. DataViews, which are discussed later in this lesson, are a customizable view of data that can also act as a data provider.
Data providers also manage currency of data. In previous data access technologies, a cursor was used to manage data currency. As the cursor moved, the current record changed and bound controls were updated. Because data access in ADO.NET is fundamentally disconnected, there is no concept of a database cursor. Rather, each data source has an associated CurrencyManager object that keeps track of the current record. CurrencyManager objects are managed through a form's BindingContext object. Data currency is discussed in detail later in this lesson.
Data Consumers
The data consumer represents the control with bound properties. In the .NET Framework, you can bind any run-time accessible property of any control to a data source. For example, you could bind the Size property of a control to a database record, or the location, or any other run-time accessible property of the control.
Data binding has a wide variety of uses. A typical scenario that involves data binding is a data entry form. Several controls, such as TextBox, CheckBox, ListBox, and so on are bound to relevant columns of a DataSet. New records are manually entered by typing values for each column into the appropriate controls displayed on the form. When a record is complete, it is added to the DataSet, which can then be used to update the database.
There are two types of data binding: simple binding and complex binding. A simple-bound control binds one record at a time to a control. For example, a Label control can be simply bound to a column in a DataTable. In such a case, it would display the member of that column for the current record.
Complex binding, on the other hand, allows multiple records to be bound to a single control. Controls such as ListBox or ComboBox can be complex bound to a single column in a DataTable or DataView. At run time, these controls would display all members of that column rather than only the current row. Complex-bound controls are usually involved in displaying choices and allowing specific rows of data to be chosen. Controls such as the DataGrid are capable of even more complex binding and can be bound to all column and rows of a particular DataTable or DataView, or even to a DataSet.
Creating a Simple-Bound Control
You can create a simple-bound control through the DataBindings property. The DataBindings property is an instance of the ControlBindingsCollection class that keeps track of and organizes which controls are bound to what data sources. At design time, the DataBindings property is displayed as a node in the Properties window. This node expands to list the properties that are most commonly data bound.
Data Binding at Run Time
You might want to change the data source that a control is bound to at run time. Or, you might not know at design time what data source a particular control might be bound to. In a third scenario, you might want to bind your control to an array or collection that is not instantiated until run time, in which case, you must set the binding in code.
Data binding for a control is managed through the control's DataBindings property, which is an instance of a ControlBindingsCollection object. At run time, you can add, remove, or clear data binding information by setting the appropriate member of the DataBindings collection.
You can bind a property to a data source by using the DataBindings.Add method. This creates a new binding association and adds it to the DataBindings collection. The Add method takes three parameters: the property name you want to bind, as a String; the data source you want to bind to, as an object; and the data member of the data source you want to bind the property to.
The CurrencyManager
The CurrencyManager object keeps track of the current record for a particular data source. There can be multiple data sources in an application at one time, and each data source maintains its own CurrencyManager. Because there can be multiple data sources represented on a single form at any given time, each form manages the CurrencyManager objects associated with those data sources through a central object called the BindingContext.
The BindingContext organizes and exposes the CurrencyManager objects associated with each data source. Thus, you can use the BindingContext property of each form to manage the position of the current record for each data source. You access a particular currency manager by supplying the BindingContext property with the data source object whose CurrencyManager you want to retrieve.
To navigate bound data in a Windows Form
Set the Position property for the appropriate BindingContext member.
Because the .NET Framework will not allow you to set the Position property to a value less than zero or greater than the upper bound of the collection, there is no possibility of an error occurring if you attempt to move before or after the end of the records.
You might, however, want to incorporate program logic to provide visual cues to users to let them know when the end or beginning of a group of records is reached. The following example demonstrates how to use the PositionChanged event of the CurrencyManager to disable back and forward buttons when the end of the record list is reached.
ADO.NET Object Model
ADO.NET Object Model
The .NET Framework is designed to change dramatically the developer's current style of developing applications, including the data access features. For the .NET applications, the primary data access technology to be used would be ADO.NET — the latest addition to the ADO model.
The ADO.NET Object Model is primarily divided into two levels:
Connected Layer: Consists of the classes that comprise the Managed Providers
Disconnected Layer: Is rooted in the DataSet
Managed Providers
Managed Providers are a collection of classes in the .NET Framework that provide a foundation for the ADO.NET programming model. The .NET Framework allows you to write language-neutral components, which can be called from any language, such as C++ or Visual Basic. In the .NET Framework, the OLE DB and ADO layers are merged into one layer. This results in high performance, and at the same time allows components to be called from any language. The Managed Data Providers include classes that can be used for the following:
Accessing data from SQL Server 7.0 and later
Accessing the other OLE DB providers
The Managed Provider for ADO.NET is the System.Data.OleDb namespace, which allows you to access OLE DB data sources. This namespace includes classes that are used to connect to OLE DB data sources and execute database queries to access and manipulate data.
To demonstrate how to open a connection to a SQL Server database and fill the DataSet with a database query result, consider the following code:
Dim connection As New
SqlConnection("server=localserver;uid=sa;pwd=;database=Sales")
Dim command As New SqlDataAdapter("SELECT * FROM Products Where
ProductID=@ID", connection)
Dim param1 As New SqlParameter("@ID", SqlDbType.Int)
param1.Value = 1
command.SelectCommand.Parameters.Add(param1)
Dim dataset As New DataSet()
command.Fill(dataset, "Products")
In this code:
connection is a SqlConnection class object that represents a connection to the SQL Server database.
command is a SqlDataAdapter class object that represents a set of data commands and a database connection.
param1 is a SqlParameter class object that represents the parameter to
be passed in the T-SQL command.
dataset is a DataSet class object that represents the DataSet that is
filled by the query results.
DataSet class
The DataSet comprises the Disconnected Layer of ADO.NET. The DataSet consists of a local buffer of tables and relations. the DataSet object model consists of Tables, Columns, Relations, Constraints, and Rows. A DataSet contains a collection of DataTables (the Tables collection). A DataTable represents one table of inmemory data. A DataTable consists of the following:
Unlike RecordSets, which are equivalent to tables in ADO, DataSets keep track of the relationships between tables if any. The DataSet is designed with a rich programming model. Th e following code creates a new DataTable with the name ProductInfo:
Dim dset As DataSet = New DataSet("ProductInfo")
Later, you can add columns to the DataTable. The columns are added to the DataTable by using the Add method on the Columns collection, and the column is assigned a name and a datatype. Finally, data is added to the table by calling the NewRow method on the DataTable and storing the column values in each DataRow.
The .NET Framework is designed to change dramatically the developer's current style of developing applications, including the data access features. For the .NET applications, the primary data access technology to be used would be ADO.NET — the latest addition to the ADO model.
The ADO.NET Object Model is primarily divided into two levels:
Connected Layer: Consists of the classes that comprise the Managed Providers
Disconnected Layer: Is rooted in the DataSet
Managed Providers
Managed Providers are a collection of classes in the .NET Framework that provide a foundation for the ADO.NET programming model. The .NET Framework allows you to write language-neutral components, which can be called from any language, such as C++ or Visual Basic. In the .NET Framework, the OLE DB and ADO layers are merged into one layer. This results in high performance, and at the same time allows components to be called from any language. The Managed Data Providers include classes that can be used for the following:
Accessing data from SQL Server 7.0 and later
Accessing the other OLE DB providers
The Managed Provider for ADO.NET is the System.Data.OleDb namespace, which allows you to access OLE DB data sources. This namespace includes classes that are used to connect to OLE DB data sources and execute database queries to access and manipulate data.
To demonstrate how to open a connection to a SQL Server database and fill the DataSet with a database query result, consider the following code:
Dim connection As New
SqlConnection("server=localserver;uid=sa;pwd=;database=Sales")
Dim command As New SqlDataAdapter("SELECT * FROM Products Where
ProductID=@ID", connection)
Dim param1 As New SqlParameter("@ID", SqlDbType.Int)
param1.Value = 1
command.SelectCommand.Parameters.Add(param1)
Dim dataset As New DataSet()
command.Fill(dataset, "Products")
In this code:
connection is a SqlConnection class object that represents a connection to the SQL Server database.
command is a SqlDataAdapter class object that represents a set of data commands and a database connection.
param1 is a SqlParameter class object that represents the parameter to
be passed in the T-SQL command.
dataset is a DataSet class object that represents the DataSet that is
filled by the query results.
DataSet class
The DataSet comprises the Disconnected Layer of ADO.NET. The DataSet consists of a local buffer of tables and relations. the DataSet object model consists of Tables, Columns, Relations, Constraints, and Rows. A DataSet contains a collection of DataTables (the Tables collection). A DataTable represents one table of inmemory data. A DataTable consists of the following:
Unlike RecordSets, which are equivalent to tables in ADO, DataSets keep track of the relationships between tables if any. The DataSet is designed with a rich programming model. Th e following code creates a new DataTable with the name ProductInfo:
Dim dset As DataSet = New DataSet("ProductInfo")
Later, you can add columns to the DataTable. The columns are added to the DataTable by using the Add method on the Columns collection, and the column is assigned a name and a datatype. Finally, data is added to the table by calling the NewRow method on the DataTable and storing the column values in each DataRow.
ADO.NET introduction
Introduction to ADO.NET
As more and more companies are coming up with n-tier client/server and Web-based database solutions, Microsoft with its Universal Data Access (UDA) model, offers highperformance access to diverse data and information sources on multiple platforms. Also, UDA provides an easy-to-use programming interface that works with practically any cool or language, leveraging the technical skills developers already have.
The Microsoft UDA model is a collection of Data Access Components, which are the key technologies that enable Universal Data Access. The Data Access Components include ActiveX Data Objects (ADO), Remote Data Service (RDS), formerly known as Advanced Data Connector (ADC), Object Linking and Embedding Database (OLE DB), and Open Database Connectivity (ODBC).
Microsoft is targeting many more such Data Access components that offer easy-tomaintain
solutions to organizations. Such solutions are aimed at allowing organizations use their own choice of tools, applications, and data sources on the client, middle tier, or server. One of the emerging components within the UDAs collection is ADO.NET.
Microsoft ADO.NET is the latest improvement after ADO. ADO.NET provides platform interoperability and scalable data access. In the .NET Framework, data is transmitted in the Extensible Markup Language (XML) format. Therefore, any application that can read the XML format can process data. It is not necessary for the receiving component to be an ADO.NET component at all. The receiving component might be a Microsoft Visual Studio–based solution or any application running on any other platform.
Although ADO.NET preserves some of the primary concepts from previous ADO models, it has been chiefly stretched to provide access to structured data from diverse sources. ADO.NET provides access to diverse data sources by using a consistent and standardized programming model. ADO.NET is upgraded to offer several advantages over previous versions of ADO and over other data access components. ADO.NET builds the foundation of data-aware .NET applications. ADO.NET brings together all the classes that allow data handling. Such classes represent data container objects that feature typical database capabilities — indexing, sorting, and views. While ADO.NET offers a solution for .NET database applications, it presents an overall structure that is not as database-centric as the ADO model.
The ADO model uses the concept of recordsets, which are the ADO representation of tables and views from a database. Although these recordsets are very flexible to use and allow access to data even when disconnected from data sources, they suffer from a major drawback. In the case of distributed and Web applications, data needs to be exchanged among different components at different tiers, which might be running on variety of platforms. Of course, the format of the data being exchanged should be understood by all components. This transmission of data requires the conversion of data types of values to some data types that are recognized by the receiving components.
This conversion is called COM marshalling. Thus, the interoperability is limited when using ADO recordsets. So, the concept of ADO recordsets fails when we look at the Internet interoperability.
Like ADO, ADO.NET also allows you to access data when disconnected from actual data sources.
However, unlike ADO, ADO.NET uses XML as the data format. Because XML is a universal data format being used, ADO.NET expands the boundaries of interoperability to the Internet. In addition, instead of recordsets, ADO.NET uses the DataSet and DataReader objects to access and manipulate data. You'll learn about these objects later in the chapter. Thus, ADO.NET is designed to perform better and be more flexible than ADO. However, to support ADO objects, the corresponding equivalents exist in ADO.NET.
Data container objects are the objects that contain data to be transmitted to the receiving components. To take full advantage of ADO.NET, you should put some effort into understanding the concept itself, rather than simply figuring out the fastest way to port your code. Whatever
.NET programming model you might choose — Windows Forms, Web Forms, or Web Services — ADO.NET will be there to help you with data access issues.
Interoperability
The ADO.NET model is designed to take maximum advantage of the flexibility provided by the large industry acceptance of XML. ADO.NET uses XML for transmitting datasets among components and across tiers. Any component that is capable of reading the XML format can process the data. It is not necessary for the receiving component to be an ADO.NET component. The component that is sending or transmitting the dataset can simply transmit the dataset to its destination without bothering with how the receiving component is implemented. The component asking for the dataset, the destination component, can be implemented as a Visual Studio application or any other application.
However, the important point to be considered is that the receiving component should be capable of accepting the XML file formatted as a dataset.
Maintainability
After an application is deployed, there might be a need for changes in the application. For example, the application might need substantial architectural changes to improve its performance. As the performance load on a deployed application server grows, system resources can become inadequate, resulting in higher response times. As a solution to these problems, the application might need to undergo architectural changes by adding tiers. Here, the problem is not the multitier application design, but rather the problem lies in increasing the number of tiers after an application is deployed. This transformation becomes easier if the original application is implemented in ADO.NET using datasets.
In ADO.NET, the communication between tiers is relatively easy, because the tiers can
transmit data through XML-formatted datasets.
Programmability
The ADO.NET model uses typed programming to manipulate objects. In typed programming, the programming environment or programming language itself recognizes the types of things that are important to users. To take full advantage of typed programming, you must know the things that are of interest to programmers and to end users. Consider the following code using typed programming in ADO.NET:
If TotalQty > DataSet1.ProductInfo("Baby Food").QtyAvailable
his code is equivalent to a line using non-typed programming and is easier to read by end users. An end user who has little or no programming experience can easily grasp the meaning of the condition being tested. Also, in non-typed programming, if the developer makes a spelling mistake by chance (for example, ProductInfo is spelled as ProdcutInfo), a run-time error will get generated. On the other hand, in typed datasets,errors in the syntax caused by misspellings are detected at compile time rather than at run time.
Performance
In ADO, while transmitting data across tiers using COM marshalling in the form of disconnected RecordSets, the values must be converted to data types that are recognized by COM. This results in poor performance. On the other hand, ADO.NET is designed to use disconnected data architecture, which in turn is easier to scale because it reduces the load on database (does not require any data type conversions). Thus, in the ADO.NET model, everything is handled at the client side, which in turn improves performance.
Scalability
The Web-based, data-centric applications require multiple users to access data simultaneously. This increases the demand on data to be accessed, making scalability one of the most critical features. Applications that use resources, such as database connections and database locks, cannot support more users to access data simultaneously, because eventually the user demand for the limited resources will exceed their supply. Because ADO.NET uses disconnected data access, applications do not retain database locks or active database connections for long durations. Hence, ADO.NET accommodates scalability by encouraging programmers to conserve limited resources, and allows more users to access data simultaneously.
As more and more companies are coming up with n-tier client/server and Web-based database solutions, Microsoft with its Universal Data Access (UDA) model, offers highperformance access to diverse data and information sources on multiple platforms. Also, UDA provides an easy-to-use programming interface that works with practically any cool or language, leveraging the technical skills developers already have.
The Microsoft UDA model is a collection of Data Access Components, which are the key technologies that enable Universal Data Access. The Data Access Components include ActiveX Data Objects (ADO), Remote Data Service (RDS), formerly known as Advanced Data Connector (ADC), Object Linking and Embedding Database (OLE DB), and Open Database Connectivity (ODBC).
Microsoft is targeting many more such Data Access components that offer easy-tomaintain
solutions to organizations. Such solutions are aimed at allowing organizations use their own choice of tools, applications, and data sources on the client, middle tier, or server. One of the emerging components within the UDAs collection is ADO.NET.
Microsoft ADO.NET is the latest improvement after ADO. ADO.NET provides platform interoperability and scalable data access. In the .NET Framework, data is transmitted in the Extensible Markup Language (XML) format. Therefore, any application that can read the XML format can process data. It is not necessary for the receiving component to be an ADO.NET component at all. The receiving component might be a Microsoft Visual Studio–based solution or any application running on any other platform.
Although ADO.NET preserves some of the primary concepts from previous ADO models, it has been chiefly stretched to provide access to structured data from diverse sources. ADO.NET provides access to diverse data sources by using a consistent and standardized programming model. ADO.NET is upgraded to offer several advantages over previous versions of ADO and over other data access components. ADO.NET builds the foundation of data-aware .NET applications. ADO.NET brings together all the classes that allow data handling. Such classes represent data container objects that feature typical database capabilities — indexing, sorting, and views. While ADO.NET offers a solution for .NET database applications, it presents an overall structure that is not as database-centric as the ADO model.
The ADO model uses the concept of recordsets, which are the ADO representation of tables and views from a database. Although these recordsets are very flexible to use and allow access to data even when disconnected from data sources, they suffer from a major drawback. In the case of distributed and Web applications, data needs to be exchanged among different components at different tiers, which might be running on variety of platforms. Of course, the format of the data being exchanged should be understood by all components. This transmission of data requires the conversion of data types of values to some data types that are recognized by the receiving components.
This conversion is called COM marshalling. Thus, the interoperability is limited when using ADO recordsets. So, the concept of ADO recordsets fails when we look at the Internet interoperability.
Like ADO, ADO.NET also allows you to access data when disconnected from actual data sources.
However, unlike ADO, ADO.NET uses XML as the data format. Because XML is a universal data format being used, ADO.NET expands the boundaries of interoperability to the Internet. In addition, instead of recordsets, ADO.NET uses the DataSet and DataReader objects to access and manipulate data. You'll learn about these objects later in the chapter. Thus, ADO.NET is designed to perform better and be more flexible than ADO. However, to support ADO objects, the corresponding equivalents exist in ADO.NET.
Data container objects are the objects that contain data to be transmitted to the receiving components. To take full advantage of ADO.NET, you should put some effort into understanding the concept itself, rather than simply figuring out the fastest way to port your code. Whatever
.NET programming model you might choose — Windows Forms, Web Forms, or Web Services — ADO.NET will be there to help you with data access issues.
Interoperability
The ADO.NET model is designed to take maximum advantage of the flexibility provided by the large industry acceptance of XML. ADO.NET uses XML for transmitting datasets among components and across tiers. Any component that is capable of reading the XML format can process the data. It is not necessary for the receiving component to be an ADO.NET component. The component that is sending or transmitting the dataset can simply transmit the dataset to its destination without bothering with how the receiving component is implemented. The component asking for the dataset, the destination component, can be implemented as a Visual Studio application or any other application.
However, the important point to be considered is that the receiving component should be capable of accepting the XML file formatted as a dataset.
Maintainability
After an application is deployed, there might be a need for changes in the application. For example, the application might need substantial architectural changes to improve its performance. As the performance load on a deployed application server grows, system resources can become inadequate, resulting in higher response times. As a solution to these problems, the application might need to undergo architectural changes by adding tiers. Here, the problem is not the multitier application design, but rather the problem lies in increasing the number of tiers after an application is deployed. This transformation becomes easier if the original application is implemented in ADO.NET using datasets.
In ADO.NET, the communication between tiers is relatively easy, because the tiers can
transmit data through XML-formatted datasets.
Programmability
The ADO.NET model uses typed programming to manipulate objects. In typed programming, the programming environment or programming language itself recognizes the types of things that are important to users. To take full advantage of typed programming, you must know the things that are of interest to programmers and to end users. Consider the following code using typed programming in ADO.NET:
If TotalQty > DataSet1.ProductInfo("Baby Food").QtyAvailable
his code is equivalent to a line using non-typed programming and is easier to read by end users. An end user who has little or no programming experience can easily grasp the meaning of the condition being tested. Also, in non-typed programming, if the developer makes a spelling mistake by chance (for example, ProductInfo is spelled as ProdcutInfo), a run-time error will get generated. On the other hand, in typed datasets,errors in the syntax caused by misspellings are detected at compile time rather than at run time.
Performance
In ADO, while transmitting data across tiers using COM marshalling in the form of disconnected RecordSets, the values must be converted to data types that are recognized by COM. This results in poor performance. On the other hand, ADO.NET is designed to use disconnected data architecture, which in turn is easier to scale because it reduces the load on database (does not require any data type conversions). Thus, in the ADO.NET model, everything is handled at the client side, which in turn improves performance.
Scalability
The Web-based, data-centric applications require multiple users to access data simultaneously. This increases the demand on data to be accessed, making scalability one of the most critical features. Applications that use resources, such as database connections and database locks, cannot support more users to access data simultaneously, because eventually the user demand for the limited resources will exceed their supply. Because ADO.NET uses disconnected data access, applications do not retain database locks or active database connections for long durations. Hence, ADO.NET accommodates scalability by encouraging programmers to conserve limited resources, and allows more users to access data simultaneously.
EVENTS IN DOT NET
Delegates and Events
Events are messages that indicate an interesting occurrence in another part of the application. When an event is raised, other parts of your application are given the opportunity to respond to that event by executing methods called event handlers.
Events are members of your class. An event represents a message that is sent to other parts of the application. When something noteworthy in the application occurs, your application can raise the event, which sends out the message. The event can wrap any arguments that contain information about the event and send them along with the event. Other parts of the application can handle the event, which means that a method is executed in response to the event.
Any method that handles an event must have the same signature as the event itself; that is, it must take the same kinds of arguments as the event passes. An event can be handled by more than one method, and a single method can handle more than one event.
Delegates
Central to the way in which events work are special classes called delegates. A delegate is essentially a type-safe function pointer. It allows you to pass a reference to the entry point for a method and invoke that method without making an explicit method call. When you declare a delegate, you specify the signature of the method that it can call and the return type.
In Visual C#, if you are creating a delegate to an instance method, you must initialize the delegate within a method. Delegates to static methods can be initialized outside a method.
Once declared and assigned, you can use the delegate to invoke the method in the same manner in which you would make a function call.
To create and invoke a delegate
Declare the delegate and provide a signature identical to the signature of the method(s) you want to invoke with this delegate.
Create an instance of the delegate that points to a method that has the appropriate signature.
Invoke the delegate by referencing its name.
Declaring and Raising Events
Declaring events is directly tied to delegates. In Visual C#, you must explicitly designate the delegate type that your event will use. Visual Basic .NET provides much of this functionality for you behind the scenes: you only need to supply the name of the event and the signature of the method it requires. A default delegate matching this signature is created.
To declare an event with Visual Basic .NET
Use the Event keyword to declare an event. Supply a signature that represents the signature of the type of method that you would like to handle the event. You can use any access modifiers, such as Public, Private, or Protected.
Implementing Event Handlers
Once an event is declared, it must be associated with one or more event handlers before it can be raised. An event handler is a method that is called through a delegate when an event is raised, and you must create associations between events and event handlers to achieve your desired results. If you attempt to raise an event in Visual Basic .NET that does not have any event handlers associated with it, nothing will happen. If you raise an event that has no event handlers in Visual C#, an error will result.
Like other members, there are instance events and Shared (static) events. Creating an event handler for an instance event requires that an association be made between a method and an object's event. The object must be declared in order for the event handler association to be created. Shared (static) events, however, belong to the class itself rather than any one instance of a class. To create an event handler for these events, you do not need to declare an instance of the class beforehand.
Event Handlers in Visual Basic .NET
In Visual Basic .NET, event handlers must be Subs and cannot return a value. You can associate a Sub with a given event by using the AddHandler keyword. AddHandler allows you to specify an event and designate a pointer to the method with which that event will be associated. The pointer is created using the AddressOf operator.
The AddHandler keyword cannot be used declaratively; it must be used inside a method. Thus, the association between the event and the event handler does not exist before the application's execution; it is added at run time. For event handler associations that exist for the lifetime of the object, the AddHandler keyword should be placed in the class's constructor.
Visual Basic .NET also allows you to create event handler associations at design time using the Handles clause. To use the Handles clause, the object must be declared with the WithEvents keyword. The WithEvents keyword informs the containing object that it will be receiving events from the contained object.
Event Handlers in Visual C#
Unlike in Visual Basic .NET, event handlers in Visual C# can return a value, and that value can be assigned to a variable in the same manner as a function call. You associate a method with a given method by creating a new instance of the appropriate delegate, which specifies the appropriate method and uses the += operator to make the association. You can also use the += operator to associate an event with an instance of a delegate that already exists.
Default delegates are provided for the events of the controls and classes of the .NET Framework base class library. If you want to manually add an event handler for one of these events, you do not need to declare a new delegate. Rather, you can create a new instance of the predefined default delegate. For example, the delegate class that is used for events for most of the controls in the System.Windows.Forms namespace is System.EventHandler.
To handle an event in Visual Basic .NET
Use the AddHandler keyword to create an association between an event and a method to handle that event. The AddressOf operator allows you to receive a pointer to the appropriate method. Event handlers must have the same signature as the event being handled.
Alternatively, you can use the Handles keyword to associate a method with an event at design time. The method must be a member method of an object that was declared with the WithEvents keyword.
To handle an event in Visual C#
Create an instance of the appropriate delegate for the event that specified the method that will handle the event, and use the += operator to associate the event with the delegate.
Event Handlers That Handle Multiple Events
You can create event handlers that handle multiple events. A common instance of when you might want to do this is when you have more than one instance of a class or control that raises the same events. For example, you might have a group of buttons on a form that share a similar role in the application. You might create a single method to handle the Click event for all of these buttons and distinguish between them by using the sender parameter.
Associating multiple events with a single handler is simple. You use the AddHandler or += operator in exactly the same way in which you would add a single event handler.
Events with Multiple Handlers
An event can be handled by more than one event handler. When an event is handled by more than one handler, all of the methods handling that event are executed. The order in which the methods execute is the same as the order in which the association was created. Thus, if event x is associated in code with handlers y, z, and q (in that order), when the event is raised, the order of handler execution will be y, z, and q. In Visual C#, if you are returning a value with your event, it will return the value of the last method executed.
To associate an event with multiple handlers, all you have to do is create an association between the event and each handler. In Visual Basic .NET, you can use the Handles clause to declaratively associate several methods with an event. If this method is used, the order of method execution is less predictable and should be tested if it has an effect on the dynamics of the application.
Removing Handlers at Run Time
You have already learned how to add event handlers dynamically. The AddHandler keyword in Visual Basic .NET and the += operator in Visual C# can be used to dynamically create associations between events and methods. You can also remove event handler associations at run time. For example, suppose you had a class that modeled a bank account that raised a NotSufficientFunds event every time the account's owner tried to submit a check for an amount greater than the account balance.
You might associate this event with two methods: a ChargeAccount method, which assesses a fee for writing a Not Sufficient Funds (NSF) check, and a Notify method, which notifies the owner of the account that his account is overdrawn. You would call the ChargeAccount method every time an NSF check was passed, but it would be redundant to call the Notify method more than once until the account balance became positive. In this case, you could remove the event handler for the Notify method, and reinsert it when the account balance returned to the positive side.
The method by which you remove an event handler is very similar to the method by which you add one. In Visual Basic. NET, you use the RemoveHandler method to disassociate an event from a delegate obtained with the AddressOf operator. In Visual C#, you use the -= operator to dynamically remove an association between an event and a method. This operator requires a reference to a delegate of the appropriate signature, and it must reference the method to be removed.
Events are messages that indicate an interesting occurrence in another part of the application. When an event is raised, other parts of your application are given the opportunity to respond to that event by executing methods called event handlers.
Events are members of your class. An event represents a message that is sent to other parts of the application. When something noteworthy in the application occurs, your application can raise the event, which sends out the message. The event can wrap any arguments that contain information about the event and send them along with the event. Other parts of the application can handle the event, which means that a method is executed in response to the event.
Any method that handles an event must have the same signature as the event itself; that is, it must take the same kinds of arguments as the event passes. An event can be handled by more than one method, and a single method can handle more than one event.
Delegates
Central to the way in which events work are special classes called delegates. A delegate is essentially a type-safe function pointer. It allows you to pass a reference to the entry point for a method and invoke that method without making an explicit method call. When you declare a delegate, you specify the signature of the method that it can call and the return type.
In Visual C#, if you are creating a delegate to an instance method, you must initialize the delegate within a method. Delegates to static methods can be initialized outside a method.
Once declared and assigned, you can use the delegate to invoke the method in the same manner in which you would make a function call.
To create and invoke a delegate
Declare the delegate and provide a signature identical to the signature of the method(s) you want to invoke with this delegate.
Create an instance of the delegate that points to a method that has the appropriate signature.
Invoke the delegate by referencing its name.
Declaring and Raising Events
Declaring events is directly tied to delegates. In Visual C#, you must explicitly designate the delegate type that your event will use. Visual Basic .NET provides much of this functionality for you behind the scenes: you only need to supply the name of the event and the signature of the method it requires. A default delegate matching this signature is created.
To declare an event with Visual Basic .NET
Use the Event keyword to declare an event. Supply a signature that represents the signature of the type of method that you would like to handle the event. You can use any access modifiers, such as Public, Private, or Protected.
Implementing Event Handlers
Once an event is declared, it must be associated with one or more event handlers before it can be raised. An event handler is a method that is called through a delegate when an event is raised, and you must create associations between events and event handlers to achieve your desired results. If you attempt to raise an event in Visual Basic .NET that does not have any event handlers associated with it, nothing will happen. If you raise an event that has no event handlers in Visual C#, an error will result.
Like other members, there are instance events and Shared (static) events. Creating an event handler for an instance event requires that an association be made between a method and an object's event. The object must be declared in order for the event handler association to be created. Shared (static) events, however, belong to the class itself rather than any one instance of a class. To create an event handler for these events, you do not need to declare an instance of the class beforehand.
Event Handlers in Visual Basic .NET
In Visual Basic .NET, event handlers must be Subs and cannot return a value. You can associate a Sub with a given event by using the AddHandler keyword. AddHandler allows you to specify an event and designate a pointer to the method with which that event will be associated. The pointer is created using the AddressOf operator.
The AddHandler keyword cannot be used declaratively; it must be used inside a method. Thus, the association between the event and the event handler does not exist before the application's execution; it is added at run time. For event handler associations that exist for the lifetime of the object, the AddHandler keyword should be placed in the class's constructor.
Visual Basic .NET also allows you to create event handler associations at design time using the Handles clause. To use the Handles clause, the object must be declared with the WithEvents keyword. The WithEvents keyword informs the containing object that it will be receiving events from the contained object.
Event Handlers in Visual C#
Unlike in Visual Basic .NET, event handlers in Visual C# can return a value, and that value can be assigned to a variable in the same manner as a function call. You associate a method with a given method by creating a new instance of the appropriate delegate, which specifies the appropriate method and uses the += operator to make the association. You can also use the += operator to associate an event with an instance of a delegate that already exists.
Default delegates are provided for the events of the controls and classes of the .NET Framework base class library. If you want to manually add an event handler for one of these events, you do not need to declare a new delegate. Rather, you can create a new instance of the predefined default delegate. For example, the delegate class that is used for events for most of the controls in the System.Windows.Forms namespace is System.EventHandler.
To handle an event in Visual Basic .NET
Use the AddHandler keyword to create an association between an event and a method to handle that event. The AddressOf operator allows you to receive a pointer to the appropriate method. Event handlers must have the same signature as the event being handled.
Alternatively, you can use the Handles keyword to associate a method with an event at design time. The method must be a member method of an object that was declared with the WithEvents keyword.
To handle an event in Visual C#
Create an instance of the appropriate delegate for the event that specified the method that will handle the event, and use the += operator to associate the event with the delegate.
Event Handlers That Handle Multiple Events
You can create event handlers that handle multiple events. A common instance of when you might want to do this is when you have more than one instance of a class or control that raises the same events. For example, you might have a group of buttons on a form that share a similar role in the application. You might create a single method to handle the Click event for all of these buttons and distinguish between them by using the sender parameter.
Associating multiple events with a single handler is simple. You use the AddHandler or += operator in exactly the same way in which you would add a single event handler.
Events with Multiple Handlers
An event can be handled by more than one event handler. When an event is handled by more than one handler, all of the methods handling that event are executed. The order in which the methods execute is the same as the order in which the association was created. Thus, if event x is associated in code with handlers y, z, and q (in that order), when the event is raised, the order of handler execution will be y, z, and q. In Visual C#, if you are returning a value with your event, it will return the value of the last method executed.
To associate an event with multiple handlers, all you have to do is create an association between the event and each handler. In Visual Basic .NET, you can use the Handles clause to declaratively associate several methods with an event. If this method is used, the order of method execution is less predictable and should be tested if it has an effect on the dynamics of the application.
Removing Handlers at Run Time
You have already learned how to add event handlers dynamically. The AddHandler keyword in Visual Basic .NET and the += operator in Visual C# can be used to dynamically create associations between events and methods. You can also remove event handler associations at run time. For example, suppose you had a class that modeled a bank account that raised a NotSufficientFunds event every time the account's owner tried to submit a check for an amount greater than the account balance.
You might associate this event with two methods: a ChargeAccount method, which assesses a fee for writing a Not Sufficient Funds (NSF) check, and a Notify method, which notifies the owner of the account that his account is overdrawn. You would call the ChargeAccount method every time an NSF check was passed, but it would be redundant to call the Notify method more than once until the account balance became positive. In this case, you could remove the event handler for the Notify method, and reinsert it when the account balance returned to the positive side.
The method by which you remove an event handler is very similar to the method by which you add one. In Visual Basic. NET, you use the RemoveHandler method to disassociate an event from a delegate obtained with the AddressOf operator. In Visual C#, you use the -= operator to dynamically remove an association between an event and a method. This operator requires a reference to a delegate of the appropriate signature, and it must reference the method to be removed.
Subscribe to:
Posts (Atom)