When I first started discussing this book with the editors at Addison-Wesley, I was a little skeptical. My gut reaction was, “Will anyone need a whole book focused on data binding?” I mean, Windows Forms is just GUI stuff, right? You drag this, you drop that, you hook up a few event handlers, and you move on to build the rest of your enterprise application—all the middle-tier goo that ties your head in knots.
As I thought more about it, I realized that a significant percentage of the work that people do in Windows Forms applications is centered around data binding, and most of the problems developers encounter are related to getting data-binding scenarios to work correctly. Add to that the multitude of new capabilities in Windows Forms 2.0 and Visual Studio 2005 related to data binding, and I quickly became convinced that this book would be a good idea. Hopefully you will agree after you have finished reading it.
Data binding is a powerful capability that has finally matured in Windows Forms 2.0 through the capabilities in the .NET Framework classes, combined with the rich designer support provided by Visual Studio 2005. By using data binding properly, you can save yourself from writing a lot of unnecessary code, provide your users a rich interactive experience for working with data that functions well, and produce code that is easy to maintain. To get it working correctly across a variety of use cases, you need to know more than how to set a few properties on controls—you need to understand what is going on under the hood, especially if you want tosupport complex scenarios that require going beyond the basic capabilities of the data-binding components in the .NET Framework.
Due to the growth of smart client architecture, Windows Forms applications are becoming more prominent in business systems. Web browser-based applications leave a lot to be desired; they cannot support many of today’s common scenarios. They don’t harness the capabilities of the client machine, and they are constrained by the request-response model of browser-based applications and the connectivity issues that surround them. So the importance of being able to code complex data application scenarios in Windows Forms is growing, and luckily the capabilities in .NET services are rapidly maturing to keep pace.
Who Should Read This Book?
The primary audience for this book is intermediate to advanced Windows Forms developers who want to learn about the new data-binding features in Windows Forms 2.0 and refine their coding practices for data-bound applications. This book dives deep into advanced features of the data-binding mechanisms in Windows Forms, data-bound controls, working with data sources, and creating custom data-bound objects and collections. If you spend a significant amount of time working with data in Windows Forms applications, then this book is for you.
If you are a beginner Windows Forms developer, this book will help you quickly learn how to support data binding. Many of the features in Windows Forms 2.0 take developers through wizards and designer features that are helpful for beginning programmers, and you will learn about those features in this book. In addition, Appendixes C and D are geared for beginner programmers to get up to speed on the basics of Windows Forms and data access.
Developing applications is more about tools and less about code. However, there is a lot of code in this book, and I have adopted some common conventions to help make things easier. References to classes, variables, namespaces, and other artifacts that manifest themselves in code are in a monospace font; this helps you distinguish an instance of the DataSet class from a conceptual discussion of data sets. Short code listings are presented inline within the text using a different monospace font.
Longer listings use a similar font, but are identified with listing numbers, for example, Listing 4.1. Within code listings, bold highlights particularly relevant portions of the code, especially “evolving code.” When I remove details that aren’t relevant to a discussion, you’ll see a comment with an ellipsis (//...). This means that more code is needed to complete the example or more code generated by the designer exists, but you don’t need it to understand the concept. On occasion, explanatory comments show context.
I use a conversational tone to discuss the kinds of objects you deal with in data-binding scenarios, for example, when describing the DataSet class in this book. However, much of the time when discussing data sets I am not talking about an instance of a DataSet class, but of an instance of a derived typed DataSet class. Although it would still be technically correct to refer to that class as a DataSet because it “is a” DataSet through inheritance, I find it annoying when too many words are called out as a code artifacts. So, when something really is a code artifact and can only be discussed correctly in that context, it’s set in the monospace font. I favor the terms data set, datatable, and table adapter when discussing concepts surrounding those types of objects, and reserve DataSet, DataTable, and CustomersTableAdapter for citing a specific class type or instance, and the capabilities defined by that code artifact.
Discussing components and controls can also be confusing, depending on how precise you want to be with your language. Technically, all controls in Windows Forms are components, because the Control class derives from the Component class. Many of the concepts surrounding data binding apply to both components, such as the BindingSource component discussed in depth in this book, and controls, such as a DataGridView control. Unfortunately, many people think of components as nonvisual objects that are used by your form and controls as objects that have a visual rendering on your forms. To avoid having to say controls and components ad nauseam, when I discuss a concept that applies to both nonvisual components and controls, I simply say components. So when you see components, think “this applies to controls as well, because they inherit from components.”
This book was written with the code base of .NET 2.0 and Visual Studio 2005 over the course of Beta 1, several Community Technical Previews, and ultimately Beta 2. The code presented in this book runs with Beta 2. I worked closely with the Windows Client product team at Microsoft, and there are no feature changes planned between Beta 2 and product release. However, some minor syntax may change between production and the release of .NET 2.0. If they do affect the code or concepts, I will provide corrections through the Web site for the book (www.softinsight.com/databindingbook), as well as updated code that will run on Visual Studio 2005 once it is released.
If you plan to run the samples available on the book’s Web site, or the walkthroughs and code listings in the book, you will need Visual Studio 2005 installed on your machine, and you will need access to a SQL Server 2000 or 2005 database server on which the Northwind sample database has been installed. Additionally, you will need to have permissions on that database to create new databases for some of the samples.
There are multiple versions of Visual Studio 2005 to choose from. All of the features discussed in this book even work in the Express versions of Visual Studio 2005, which are free. You can develop all of the samples in this book in Visual C# 2005 Express or Visual Basic 2005 Express with SQL Server 2005 Express, but because Express versions of Visual Studio don’t support data connections using server paths (they only support file path-based connections to SQL Express databases), you will have to create the sample databases and data in SQL Express, and then alter the connection strings and the way you set up connections based in Express.
The samples and scripts included in the book assume you are working on a machine with a standard, professional, or enterprise version of Visual Studio 2005 installed, along with a default instance of either SQL Server 2000 or 2005 on your local machine. To run the samples without that configuration will require modifying the connection string settings for all of the samples that run against a database. The modifications needed are discussed on the book’s Web site, and the differences in connection strings are highlighted in many places in the sample code.
Additionally, Northwind doesn’t ship with SQL Server 2005, but is available as a separate installable download that will work with SQL Server 2005 from MSDN Downloads at www.microsoft.com/downloads/details.aspx? FamilyID=06616212-0356-46A0-8DA2-EEBC53A68034&displaylang=en. The download provides scripts and MDF files that can be attached to SQL Server 2005 or used with SQL Server 2005 Express.
Choice of Language
I chose to write this book in C#. The download code is available in both C# and Visual Basic code. It is a fact of life that there wi...