What Is a Data Source? | Hitchhikers Guide to Visual Studio and SQL Server: Best Practice Architectures and Examples, 7th Edition (Microsoft Windows Server System Series)

A "Data Source" (according to Visual Studio 2005's new^[1] definition) is a means of generating one or more TableAdapter classes. The Data Source XSD designer (shown in Figure 6.1) and the Data Source Configuration wizard are designed to provide a way to generate visualize relational tables, stored procedures, views, or objects exposed via an XML Web Service or business object interface. These Data Source objects expose named DataSet and TableAdapter classes as icons that can be dragged from the Data Sources window to a Windows Forma process that instructs Visual Studio to generate the connection, linkage, binding, navigation, and action queries code needed to display, capture parameters, show position, navigate through a query's rowset, and update the data on demand.

^[1] The term "Data Source" has been used for a variety of classes, objects, concepts, and other random stuff for decades.

Figure 6.1. A populated Data Source Designer window.

The code generated by the Data Source Configuration wizard is saved to a "Designer" file in your solution that can be inspected (but I don't recommend that you change it) to see how the class is implemented.

During manual configuration (a required step, as far as I'm concerned) you should:

Refine the query being executed. For example, you can add a WHERE or TOP clause to limit the number of rows returned.
Define parameters to further focus the query.
Designate what code and UI elements are generated when you drag the icon to a Windows or ASP.NET Form.
Designate the code methods used to populate the underlying custom strongly typed DataTable objects.
Add TableAdapter classes to the Data Source and tune the relationships between those classes.
Define or refine the code used to update the target rowset.
Specify how each TableAdapter column is to be rendered in bound controls.
You can choose appropriate Windows forms controls to display the column value or write a custom control to display it.

Tip

The .XSS file created by Visual Studio is used to map the objects shown in the Data Sources Designer window.

The aforementioned wizards also deal very nicely with query parameters (if you specify them) and provide a clean navigation tool to step from row to row to implement simple control binding. I built a sample of this UI by creating a "codeless" interface to the AuthorsByYearBorn stored procedureincluding the query parameters (as shown in Figure 6.2).

Figure 6.2. Data Source Configuration wizardgenerated code populated this form.

Simple control binding connects data from a data source (DataTable single Row value) to a single-item control (like a TextBox). In contrast, "complex" data binding is where you point the DataSource property at a DataTable (or, better yet, a DataView) and let the control display all rows at once.

While the Data Source Configuration wizard works pretty well for simple (and small) database tables, it quickly loses steam when you try to leverage it to access large tables, Web Services, or business objectsthese aren't nearly as intuitive, and you'll end up doing a lot more work than you might feel is warranted.

For those transitioning from earlier versions of Visual Studio, you might recall that strongly typed DataSet classes were created by their own wizard that was launched from the Data menu. Well, Microsoft has chosen to hide that wizardthey want you to use their new shiny Data Source wizard. Thankfully, the functionality and wizard are still there; you just have to turn over a few rocks to find itif you still want to use it. ASP and Web Service developers won't have a choice. They'll still have to use this "ancient" method to construct their strongly typed classes. I'll walk through this process later in this chapter.

As I said, the Data Sources XSD designer is driven by the Data Source Configuration wizard, which creates strongly typed TableAdapter classes. It accomplishes this by capturing (or helping you construct) a ConnectionString that identifies the source of the data, the user credentials, and other options used to establish a link (a connection) to the data. The ConnectionString you build is persisted to the app.config file and can be manipulated by using the new "Settings" tab of the Project property page. The interactive DSCW explores the targeted data source and enumerates all visible^[2] objects. For a relational database, this means you'll see a dialog listing all of the Tables, Views, and stored procedures your credentials (those used to launch Visual Studio) have a right to see. For a Web Service or business object, you should see the methods the service or object exposes.

^[2] The object "explorer" shows only objects that you have rights to see. I discuss rights later in this chapter.

Tip

I walk through the process of building a Data Source step by step later in this chapter.

In the process of running the DSCW, the UI populates a tree-view of the available objects and permits you to choose which of these to access. Once you select one or more objects, the DSCW generates a strongly typed TableAdapter for each of the selected objects and a (giant) XSD file that describes the Data Source in XML. By default, a "Fill" and "GetTable" method are generated for each objectreturning all of the rows from the objects using expensive SELECT queries with no WHERE clauses. For example, creating a Data Source against the four-column Authors table inserts 853 lines of code into the dsAuthors.Designer.vb and generates a 115-line XSD file. It does not take a nuclear scientist to know that it makes sense to be judicious about the number of objects you choose to access. No, you don't have to (and probably shouldn't) return all columns from selected objects. When working with Tables and Views, the wizard permits you to specify which columns to fetch. It also makes sense to tune the auto-generated queries to accept parameters that limit the scope of the SQL. I'll show you just how this is accomplished as I walk you through the DSCW step by step later in this chapter.

Make no mistakethe Data Sources window is not a "Data View" window or Server Explorer. When you include a Data Source in your application, the compiled code you distribute and load into memory includes the thousands of lines of generated code created by the DSCWeven if your code never touches a single one of the defined TableAdapter objects. The size of the compiled DLLs can significantly impact the performance of your application. For ASP.NET web sites, a larger memory footprint directly impacts the number of users you'll be able to support (scalability).