ADO.NET assumes a model for data access: You open a connection, get data or execution operation, and then close the connection. ADO.NET provides two basic strategies for using this model. A model is to store data in a data set, which is a buffer that you can use when you connect to the data source. To use a dataset, you can create an instance of the dataset, then fill it from the data source using the data adapter. You can then use the data in the data set, for example, by binding the control to the data set member. For more information, see the Data Set.
Another policy is to perform operations directly on the database. In this model, a data command object containing a SQL statement or a reference to a stored procedure can be used. You can then open a connection, execute the command to perform the operation, then turn off the connection. If the command returns the result set (ie if the command is executed), you can use the data reader to obtain the data, the function of the data reader is similar to the efficient read-only cursor. The data reader is then used as a source of data binding. For more information, see the Datacommand object in Visual Studio.
Each strategy has a specific advantage, which will be described in detail in each section below. You should select the policy based on your data access.
Note When deploying an application containing Visual Studio data access component, you must ensure that the user installing the application has a version 2.7 or higher of the Microsoft Data Access Component (MDAC). For more information, see
Add Microsoft Data Access Components Startup Conditions
.
Store data in the data set
The frequent model of data accesses in the Visual Studio .NET application is to store data in the data set and use the data adapter to read and write data in the database. (.NET application uses ".NET Framework": public language running library and hosted classes.) The superiority of the data set model is:
Using multiple tables a dataset can contain multiple result tables, which use these tables as discrete objects. You can use these tables alone or navigate between them as a parent child table. Operating a table within a data set of multiple sources represents data from multiple different sources, such as data from different databases, XML files, spreadsheets, and the like, can appear in the same data set. Data After the data set, you can operate the data and associate data in the same format, as if they come from a single source. The interlayer mobile data in the distributed application is saved in the data set, which allows you to easily move it between the application's representation layer, the business layer, and the data layers. Data exchange data sets with other applications provides a powerful data exchange, which can exchange data with other components of your application and other applications. The data set contains widespread support for many features, such as the sequence of data to XML and read and write XML architectures. Data Binding If you are using a form, data binding the controls into the data set is usually easier than the execution of the data value by programming. Maintenance records for reuse through the dataset, you don't need to query the database again to reuse the same records. Using Data Sets, you can filter and sort your records and you can use the data set as a data source (if you are patching). Easier Programming When using a data set, you can generate a class file that represents its structure as an object (for example, the Customers table within the data set can be accessed as DataSet.customers objects). This makes it easier to program with it, more clearly more unlibrated, and is supported by Visual Studio tools such as intelligent awareness, "Data Adapter Configuration Wizard".
Directly execute database operations
You can also interact with the database directly. In this model, a data command object containing a SQL statement or a reference to a stored procedure can be used. Then you can execute the command to do this. If the command returns the result set (ie if the command is executed), you can use the data reader to obtain the data, the function of the data reader is similar to the efficient read-only cursor. Safety instructions
CommandType
Attribute settings
When Text's data command, please check the information sent from the client, and then pass it to the database. Malicious users may try to send (insert) modified or other SQL statements to obtain unauthorized access or destroy the database. Before transferring the user into the database, it should always be confirmed to be valid. If possible, always use the parameterized query or stored procedure, which is the best measures.
Direct execution of database operations has specific advantages, including:
Additional functions As mentioned earlier, some operations can only be done by executing the data command, such as executing DDL commands. More controls performed by using commands and data readers (if you are reading data), you can control more about how to perform SQL statements or stored procedures and what will become results or return values . Less system overhead reads and writes directly in the database, you don't have to store data in the data set. Since the data set requires memory, some system overhead in the application can be reduced. This is especially true when you intend to use only a data (such as displaying search results) in a web page). In this case, you may not need to create and fill this step when displaying data. In some cases, more programming is less in a few cases (especially web applications), saving the data set status requires additional programming. For example, in the Web Forms page, each round-trip process is recreated; unless programming is saved and restored, each round-trip process will give up and recreate the data set. If you use a data reader to read directly from the database, you can avoid the additional steps required to manage the data set.
Due to the stateless characteristics of the web application and corresponding issues associated with the storage data set, the database is sometimes more practical in the web application. For more information, see Introduction to Data Access to the Web Form Page.
Access data suggestion
Some suggestions will be provided below that these recommendations apply to data access policies used with specific type applications.
Web form
Usually use data commands; to get data, use the data reader. Because each Web Form page is recreated, the page is recreated and the controls and components are created, so each time you create and populate the data set, it is usually low in efficiency, unless you want to put a data set between the round-trip process. Caching.
Use the data set in the following situations:
You want to use a plurality of separate tables or tables from different data sources. You are swaping data with other applications or components such as XML Web Services. You need to perform comprehensive processing by each record obtained from the database. If you use a data command and a data reader, you can read each record while processing it may cause the connection to keep an open state, which may affect your application performance and scalability. If the data processing involves interdependent records (for example, looking for information in related tables). If you want to perform an XML operation, such as the xslt conversion on the data. If you like a simple programming method provided by the data set.
For more information, see Web Data Access Policy Suggestions.
XML Web SERVICES
XML Web Services is an ASP.NET web application, so use the same model as web form page: Create and discard XML Web Services each time you call it. This suggests that the data access model of XML Web Services is substantially the same as the data access model for web forms. However, XML Web Services is usually an intermediate layer object, and its main use is usually exchanged with other applications on the web. Use the data set in the following situations:
Your XML Web Services sends and receives data; for example, send data as a return value of the method and receives data as a method parameter. This is a basic choice in XML Web Services; even for other reasons you can consider using data commands, but data exchange with other components, almost always means that you should use the data set. Any reason why it is suitable for web forms is made above.
Use the data command (and use the data reader in order to use):
XML Web Services is searching scalar values. XML Web Services is performing non-inquiry operations, such as DDL commands. XML Web Services Positive Use stored procedures to perform logic in the database.
Windows form
In general, the data set is used in a Windows form. The Windows Form is usually used for the fat client, where each user does not create and abandon the form (and its data), which is the same as the Web form. The Windows Form Application has also provided a data access scheme for maintaining a record cache (eg, a record in a form one by one in the form.
Specifically, please use the data set as follows:
If you are repeating the same record, for example, the user is allowed to navigate between records. If you are using a Windows Form Data Binding structure, this structure is designed to use a data set. Other reasons listed under the above web form.
Use the data command (and use the data reader in order to use):
If you are working from a database, if you are performing a non-inquiry operation, such as a DDL command. If you are getting read-only data to display in a form, for example, create a report. It is also important to note that if you do not need to keep data available after accessing the data, use the data command.
