.NET data access—and that includes the new .NET Core—is based on ADO.NET, which is composed of a set of classes that define interfaces to access any kind of data source, both relational and non-relational. The IDE includes a customary number of tools in order to help connect to databases and create ORMs (Object Relational Models) that map the objects in the database to objects in a .NET language world.

The IDE's options include data manipulation in the memory and presenting data to the user in several user interfaces and dialog boxes, both at development time and runtime.

Visual Studio has several tools and designers that work with ADO.NET to help you connect to databases, manipulate the data in the memory, and present the data to the user. The official schema of the ADO.NET architecture is exposed in this image of MSDN:

As you can see, we have two sets of classes in this diagram: those of the .NET Framework data provider we use and those related to the DataSet object, which is an in-memory representation of part (or all) of the data tables, relations, and constraints included in the original database.

Both sets of classes include data maintenance, although the dataset offers some extra functionalities, useful in many cases, such as batch updates and provider-agnostic data storage. With this functionality, some impossible things are available, such as linking two tables via relationships, independently of the possible diverse origin of those tables (say, an Oracle table, a SQL server table, and a Excel Spreadsheet). Reinforce these relations at execution time, establishing business logic that is quite complex to code otherwise.

Let's create a new WPF project, which we will use to read some data from our database and present it in a data grid inside a WPF window.

Once we've created the basic project, let's add a new dataset. To do this, just select Add New in project's options, and you'll be presented with a blank design surface, in which you can drag and drop any table of the list of tables you'll see in the Solution Explorer pointing to the AdventureWorks database. After choosing the Person table, you can add Code Map, selecting that option in the Solution Explorer's top icons. You'll have two windows as a result: one showing the data structure and another with the code schema, as shown in the following screenshot:

You can see that a new set of nested files has been created in your solution, showing several files that hold the class definitions related to the connection and the relational mapping I mentioned earlier:

A look at the contents of the C# files generated will show a large number of functionalities that provide the majority of resources we need for CRUD operations, Stored Procedures calls, connection management, searches, and much more.

Configuring the user interface

We can add a new DataGrid object to our empty window, to be later populated with the data we read.

The first step to get the data directly when the window shows up is adding a Loaded event declared in the XAML editor at the end of the <window> declaration:

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
  xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
  xmlns:local="clr-namespace:WpfData1"
  xmlns:DataSetAWTableAdapters="clr- namespace:WpfData1.DataSetAWTableAdapters" x:Class="WpfData1.MainWindow" mc:Ignorable="d" Loaded="Window_Loaded" Title="MainWindow" Height="350" Width="622">

This declaration, in the C# code, has created a window_load event handler. Next, we can use the PersonTableAdapter object created when defining our model in very simple way to load and bind data to our DataGrid object:

private void Window_Loaded(object sender, RoutedEventArgs e)
{
  var pta = new PersonTableAdapter();
  dataGrid.ItemsSource = pta.GetData().DefaultView;
}

Here, the PersonTableAdapter code takes care of establishing a connection to the database, loading the data previously defined in its internal SQLCommand object and returning a DataView object suitable to be assigned to DataGrid for the automatic creation of columns (as many as the table has), as shown in the next screenshot:

By the way, the black toolbar on top of the data grid's header is a debugging option offered by Visual Studio that shows/hides layout adorners, enables/disables selection, and—optionally—takes you to a new window, Visual Tree, where you can inspect all elements in the XAML user interface and check their dependencies and values at runtime, as indicated in the arrow pointing to LastName Miller in the list.

If you take a look at the properties of the TableAdapter and DataSet objects, you'll discover a very rich set of objects prepared for all sorts of data manipulation.

This was just a simple demo to check how easy it is to read data using ADO.NET if you use the ORM objects created for us by Visual Studio. However, ADO.NET is not the technology most commonly used these days, since other options are preferred when accessing relational databases, especially Entity Framework.