Creating Data Applications

Visual Studio provides many design-time tools to help you create applications that access data. This introduction presents an overview of the basic processes involved in creating applications that work with data. The information here deliberately skips over many details and is designed as a source of general information and a jumping-off point to the many other Help pages associated with creating a data application.

As you develop applications that access data in Visual Studio, you will have different requirements. In some cases, you might simply want to display data on a form. In other cases, you might need to devise a way to share information with other applications or processes.

No matter what you do with data, there are certain fundamental concepts that you should understand. You might never need to know some of the details of data handling — for example, you might never need to programmatically create a database — but it is very useful to understand the basic data concepts, as well as the data tools (wizards and designers) available in Visual Studio.

A typical data application uses most of the processes illustrated in the following diagram:

The Data Cycle

Data Cycle graphic

As you create your application, think of the task you are trying to accomplish. Use the following sections to assist in finding the Visual Studio tools and objects that are available to you.

Note

Visual Studio provides wizards to simplify several of the processes shown in the previous diagram. For example, running the Data Source Configuration Wizard provides your application with enough information to connect to data, create a typed dataset to receive the data, and bring the data into your application.

To quickly see how Visual Studio helps you in developing data applications, see Walkthrough: Creating a Simple Data Application.

Connecting to Data

To bring data into your application (and send changes back to the data source), some kind of two-way communication needs to be established. This two-way communication is typically handled by objects in your data model.

For example, a TableAdapter connects applications that use datasets to a database, and ObjectContext connects entities in the Entity Framework to a database. Visual Studio provides several tools to assist in creating connections that can be used by your application. For more information on connecting your application to data, see Connecting to Data in Visual Studio.

To learn how to use datasets to connect your application to data in a database, see Walkthrough: Connecting to Data in a Database (Windows Forms).

For information on connecting to data through a conceptual model, see the Entity Framework Quickstart.

Preparing Your Application to Receive Data

If your application uses a disconnected data model you need to temporarily store the data in your application while you work with it. Visual Studio provides tools that help you create the objects that your application uses to temporarily store data: datasets, entities, and LINQ to SQL objects.

Note

An application that uses a disconnected data model will typically connect to a database, run a query bringing data into the application, disconnect from the database, and then manipulate the data offline before reconnecting and updating the database.

For more information on creating typed datasets in your application, see Preparing Your Application to Receive Data. For additional information about using datasets in n-tier applications, see How to: Separate Datasets and TableAdapters into Different Projects.

To learn how to create a dataset, complete the procedures in Walkthrough: Creating a Dataset with the Dataset Designer.

To learn how to use the Entity Data Model Wizard to generate entities from a database, see How to: Create a New .edmx File (Entity Data Model Tools).

To learn how to create LINQ to SQL objects, complete the procedures in Walkthrough: Creating LINQ to SQL Classes (O/R Designer).

Fetching Data into Your Application

Whether your application uses a disconnected data model or not, you need to be able to fetch data into your application. You bring data into your application by executing queries or stored procedures against a database. Applications that store data in datasets execute queries and stored procedures by using TableAdapters, whereas applications that store data in entities execute queries by using LINQ to Entities or by connecting entities directly to stored procedures. For more information about creating and editing queries that use TableAdapters, see How to: Create TableAdapter Queries and How to: Edit TableAdapter Queries.

For information about using stored procedures with the Entity Framework, see How to: Map Modification Functions to Stored Procedures (Entity Data Model Tools).

For more information about loading data into datasets, and about executing queries and stored procedures, see Fetching Data into Your Application.

To learn how to load data into a dataset, complete the procedures in Walkthrough: Displaying Data on a Windows Form and examine the code in the form-load event handler.

To learn how to load data into LINQ to SQL objects, complete the procedures in Walkthrough: Creating LINQ to SQL Classes (O/R Designer).

To learn how to create and execute a SQL query, see How to: Create and Execute an SQL Statement that Returns Rows.

To learn how to execute a stored procedure, see How to: Execute a Stored Procedure that Returns Rows.

Displaying Data on Forms

After bringing data into your application, you will typically display it on a form for users to view or modify. Visual Studio provides the Data Sources Window, where you can drag items onto forms to automatically create data-bound controls that display data. For more information on data binding and displaying data to users, see Binding Controls to Data in Visual Studio.

To learn how to present data to users, complete the procedures in the following walkthroughs (paying particular attention to the process of dragging items from the Data Sources window):

Editing Data in Your Application

Once your users have been presented with data, they will likely modify it by adding new records and editing and deleting records prior to sending the data back to the database.

For more information on working with the data once it is loaded into your dataset, see Editing Data in Your Application.

For more information on working with data in an Entity Framework application, see Working with Objects (Entity Framework).

Validating Data

When making changes to data, you will typically want to verify the changes before allowing the values to be accepted back into the dataset or written to the database. Validation is the name of the process for verifying that these new values are acceptable for the requirements of your application. You can add logic to check values in your application as they change. Visual Studio provides tools that assist in adding code that validates data during column and row changes. For more information, see Validating Data.

To learn how to add data validation to your application, see Walkthrough: Adding Validation to a Dataset.

To learn how to add validation to a dataset that is separated into an n-tier application, see How to: Add Validation to an N-Tier Dataset.

For more information on validating data in an Entity Data Model, see How to: Execute Business Logic When Saving Changes (Entity Framework).

Saving Data

After making changes in your application (and validating those changes), you typically want to send the changes back to the database. Applications that store data in datasets typically use a TableAdapterManager to save data. For more information, see TableAdapterManager Overview. Entity Framework applications use the SaveChanges method to save data.

For more information on sending updated data back to a database, see Saving Data.

To learn how to send updated data from a dataset to a database, complete the procedures in Walkthrough: Saving Data from Related Data Tables (Hierarchical Update).

For more information about saving data in an Entity Framework application, see Saving Changes and Managing Concurrency.