Chapter 6. Building Data Sources, DataSets, and TableAdapters

This chapter explores the new Visual Studio 2005 paradigm used to create and use "strongly typed" TableAdapter classes using the Data Source Configuration wizard. A strongly typed data structure (as I discuss in detail later in this chapter) is simply a class that exposes the columns of a rowset as property variables whose datatype has been assigned based on the metadata gleaned from the SELECT query (at design time). As you'll figure out before long, I'm not a whole-hearted fan of this approach, for a number of reasons that will become apparent as you read the chapter. Suffice it to say that a strongly typed data structure does not necessarily buy you much beyond the ability to fetch data from memory (a lot) faster and provide what's known as "type safety." That is, a type-safe data structure can't accept a value outside of the type. Integers can accept only properly sized integers, floats can take only property scaled floats, and strings can take only strings. That's cool, but that does not mean the data is validjust the right type, but I'm getting ahead of myself.

In earlier versions of Visual Studio, you could use the Generate DataSet wizard to construct strongly typed DataSet classes. I'll talk about that approach, as well, later in this chapterno, it's not where you might expect to find it. The entire paradigm is built around strongly typed classes. As you'll see, this concept is the hinge-pin of Microsoft's push toward its Service-Oriented Architecture (SOA). It continues to promise better performance, better developer productivity, better data purity, and more work for consultants who understand how to use it. Just how well it delivers on those promises is a matter of discussion.

In this chapter, I'll start by touring the process of designing and modifying Data Sources and TableAdapter classes, as well as creating strongly typed DataSet classes. You'll see where these classes make sense and make it clear where they just get in the way. Along the way, I'll briefly point out the XML structures used to implement these classes, but I don't plan to wade into that swamp. At least one of us does not think a developer needs to edit XML to get his or her job donebut it doesn't hurt to know what's going on behind the curtains. When I discuss the ReportViewer control in Chapter 14 "Creating and Managing Reports", you'll see how creating a Visual Studio Report can be facilitated by using the Data Source Configuration wizard (DSCW) and TableAdapter Configuration wizard (TACW) to auto-generate a TableAdapter, but you'll also see how that's really not necessary. I'll also show you how to actually use these generated code classes in your applications.

IMHO

Frankly, the Data Source and TableAdapter class make impressive, virtually "codeless" demos, but don't feel threatenedI don't think they're going to completely replace the connection management, data access, and binding code in serious applications.

Incidentally, you won't find the Data Source Configuration wizard when you open a Web Service or ASP.NET projectthey aren't supported in those development modes in Visual Studio 2005. For those project types, you're still going to have to use the Server Explorer to expose data sources (Tables, Views, and stored procedures) and drag and drop these objects to your ASP forms or bound controls.