ADO.NET is a model intended primarily for disconnected data access. ADO.NET provides two strategies for you to work with this model.
1. Store data in a dataset, which is an in-memory cache of records you can work with while disconnected from the data source. To use a dataset, you use a data adapter to fill it from the data source. You then work with the data in the dataset.
2. Perform operations directly against the database. In this strategy, you use a data command object. You can then open a connection, execute the command to perform the operation, and then close the connection.
Each strategy has its own advantages. So you should choose a strategy based on what your data-access requirements are.
Advantages of Storing Data in Datasets
The advantages of the dataset model are:
· Data exchange with other applications - A dataset provides a powerful way to exchange with other components of your application and with other applications.
· Moving data between tiers in a distributed application - By keeping data in a dataset, you can easily move it between the presentation tier, business tier, and data tier of your applications.
· Working with multiple tables - A dataset can contain multiple tables. You can work with the tables individually or navigate between them as parent-child tables.
· Maintaining records for reuse - A dataset allows you to work with the same records repeatedly without re-querying the database.
· Manipulating data from multiple sources - The tables in a dataset can represent data from many different sources. Once the data is in the dataset, you can manipulate it and relate it as if it had come from a single source.
· Data binding - If you are working with forms, it is usually easier to bind controls to data in a dataset than it is to programmatically load data values into the control after executing a command.
· Ease of programming - When you work with a dataset, you can generate a class file that represents its structure as objects. This makes it easier, clearer, and less error-prone to program with, and is supported by Visual Studio tools such as IntelliSense, the Data Adapter Configuration wizard, and so on.
Advantage of performing Database Operations Directly
The advantages of performing database operations directly:
· More control over execution - By using commands, you get more direct control over how and when an SQL statement or stored procedure is executed and what becomes of the results or return values.
· Less overhead - By reading and writing directly in the database, you can bypass storing data in a dataset. Because the dataset requires memory, you can reduce some overhead in your application. This is especially true in situations where you intend to use the data only once. In that case, creating and filling a dataset might be an unnecessary step in displaying the data.
· Extra functionality - There are some operations, such as executing DDL commands, that you can run only by executing data commands.
· Less programming in some instances - In a few instances, particularly Web applications, there is some extra programming required to save the state of a dataset. If you use a data reader to read directly from the database, you avoid the extra steps required to manage the dataset.
Recommendations for Accessing Data
The following sections provide recommendations for which data-access strategy to use with specific types of applications.
Use data commands in general; use a data reader to fetch data. Because Web Forms pages and their controls and components are recreated each time the page makes a round trip, it often is not efficient to create and fill a dataset each time, unless you also intend to cache it between round trips.
Use datasets under the following circumstances:
· You need to perform extensive processing with each record you get from the database.
· You want to work with multiple separate tables or tables from different data sources.
· If your data processing involves interdependent records.
· If you want to perform XML operations such as XSLT transformations on the data.
· You are exchanging data with another application or a component such as an XML Web service.
· If you prefer the ease of programming provided by datasets.
XML Web Services
XML Web services are ASP.NET Web applications, and therefore use the same model as Web Forms pages: the XML Web service is created and discarded each time a call is made to it. This suggests that the data-access model for an XML Web service is largely the same as it is for Web Forms. However, XML Web services are often middle-tier objects, and an important part of their purpose is often to exchange data with other applications across the Web.
Use a dataset if:
· Your XML Web service sends and receives data.
· For any of the reasons listed above for Web Forms.
Use a data command if:
· The XML Web service is performing a non-query operation, such as a DDL command.
· The XML Web service is retrieving a scalar value.
· The XML Web service is calling a stored procedure to execute logic within the database.
In general, in a Windows Form, use a dataset. Windows Forms are typically used on rich clients where the form is not created and discarded with each user operation, as with Web Forms. Windows Forms applications also traditionally offer data-access scenarios that benefit from maintaining a cache of records, such as displaying records one by one in the form.
Use a dataset if:
· You are using the Windows Forms data-binding architecture, which is specifically designed to work with datasets.
· You are working with the same records repeatedly, such as allowing a user to navigate between records.
· For any of the other reasons listed under Web Forms above.
Use a data command if:
· You are performing a non-query operation, such as a DDL command.
· You are getting a scalar value from the database
· You are getting read-only data to display in a form — for example, creating a report. Stated differently, if there is no need to keep the data available after accessing it, use a data command.
What is ADO.net
ADO.net is data access architecture for the Microsoft .NET Framework.
· In ADO, Record set, is like a single table or query result, while in ADO.net Dataset, can contain multiple tables from any data source.
Difference between ADO.net Dataset and
· A DataSet can represent an entire relational database in memory, complete with tables, relations, and views.
A DataSet is designed to work without any continuing connection to the original data source.
Data in a DataSet is bulk-loaded, rather than being loaded on demand.
There's no concept of cursor types in a DataSet.
DataSets have no current record pointer You can use For Each loops to move through the data.
You can store many edits in a DataSet, and write them to the original data source in a single operation.
Though the DataSet is universal, other objects in ADO.NET come in different versions for different data sources.
· Data Source: It can be a database, text file, excel spread sheet or an XML file.
· Data Provider: A set of libraries that is used to communicate with data source. Eg: SQL data provider for SQL, Oracle data provider for Oracle, OLE DB data provider for access, excel or mysql.
· SQL Connection: It establishes connection.
· SQL Command: It allows to manipulate database by executing stored procedure or sql statements.
· SQL DataReader: It provides a forward-only, read-only, connected recordset.
· DataSet: dataset is a disconnected, in-memory representation of data. It can contain multiple data table from different database.
· SQL DataAdapter: It populates dataset from data source. It contains a reference to the connection object and opens and closes the connection automatically when reading from or writing to the database.
· DataView: It provides a means to filter and sort data within a data table.
Difference between Dataset and DataReader Object
Points to be consider while choosing between the DataSet and DataReader objects.
Supports multiple tables from different databases
Supports a single table based on a single SQL query of one database
Bind to multiple controls
Bind to a single control
Forward and backward scanning of data
Forward-only scanning of data
Slower access to data
Faster access to data
Greater overhead to enable additional features
Lightweight object with very little overhead
Supported by Visual Studio .NET tools
Must be manually coded
SQLDataReader makes exclusive use of connection
The SQLDataReader object makes exclusive use of its SQLConnection object as long as it is open. You are not able to execute any other SqlCommand objects on that connection as long as the SQLDataReader object is open. Therefore, you should always call SQLDataReader.close() as soon as you are done retrieving data.
Strongly Typed Dataset Object
Strongly typed Dataset object allows you to create early-bound data retrieval expression.
Advantage of Strongly Typed dataset
It is faster than late-bound data retrieval expression.
Its column name is shown in intellisense as you type code.
Improving Performance with Connection Pooling
Opening a connection is a database-intensive task. It can be one of the slowest operations that you perform in an ASP.NET page. Furthermore, a database has a limited supply of connections, and each connection requires a certain amount of memory overhead (approximately 40 kilobytes per connection).
If you plan to have hundreds of users hitting your Web site simultaneously, the process of opening a database connection for each user can have a severe impact on the performance of your Web site.
Fortunately, you can safely ignore these bad warnings if you take advantage of connection pooling. When database connections are pooled, a set of connections is kept open so that they can be shared among multiple users. When you request a new connection, an active connection is removed from the pool. When you close the connection, the connection is placed back in the pool.
Connection pooling is enabled for both OleDb and SqlClient connections by default.To take advantage of connection pooling, you must be careful to do two things in your ASP.NET pages. First, you must be careful to use the same exact connection string whenever you open a database connection. Only those connections opened with the same connection string can be placed in the same connection pool. For this reason you should place your connection string in the web.config file and retrieve it from this file whenever you need to open a connection
To take advantage of connection pooling in your ASP.NET pages, you also must be careful to explicitly close whatever connection you open as quickly as possible. If you do not explicitly close a connection with the Close() method, the connection is never added back to the connection pool.
SQL Injection Problem
SQL injection is a strategy for attacking databases.
An ASP page asks the user for a name and a password, and then sends the following string to the database:
SELECT FROM users WHERE username = 'whatever' AND password = 'mypassword'
It seems safe, but it isn't. A user might enter something like this as her user name:
' OR 1>0 --
When this is plugged into the SQL statement, the result looks like this:
SELECT FROM users WHERE username = '' OR 1>0 -- AND password = ''
This injection comments out the password portion of the statement. It results in a list of all the names in the users table, so any user could get into your system.
The easiest way to prevent this sort of injection is to parse the SQL string and remove any occurrences of "--" before passing the statement.
You also have to beware of injections that contain semicolons because semicolons delimit SQL statements. Think about the implications of a user name like this:
' OR 1>0 ; DELETE Customers ; --
There are numerous ways a malicious user might penetrate your system using SQL injection and various defenses, but the simplest approach is to avoid dynamic SQL. Instead, use stored procedures everywhere. Thanks to the way SQL passes parameters, injections such as those above will produce errors, and the stored procedure will not execute.