计算机英语翻译－－题目七

What Is Data Binding?

Data binding is a solution to a problem that developers used to solve over and over in user-interface applications. In the past, if you wanted to present data to a user, you had to retrieve the data from where it was stored and get it into your application. You then had to write custom code to render the data with graphics, or you could manually populate properties on controls with the data to display it. The way that you approached this would be different for each situation, each type of data, and each type of presentation that you provided. If the user was allowed to interact with the data and make modifications or additions to it through the user interface, you had to write custom code to collect the modified values from the user interface and push them back into the underlying data objects or collections in memory. You also needed code that persisted the changed values to the data store from which it came. This required a lot of repetitive and error-prone code, which always cries out for a better solution.
Data binding encapsulates all of these steps into components that help present the data, which reduces the amount of code that you need to write. Some of that code goes into the data-bound controls that present the data, and some of it goes into nonvisual components that make data binding easier.
Data binding also involves providing easy-to-understand patterns for how you write code to hook up data to controls for presentation and editing. Finally, it involves developer tools that help write the code for you, using intuitive design-time interactions provided by Visual Studio 2005. The overall process of presenting and editing data is still basically the same as when no data binding is involved, but using data binding significantly reduces the amount and complexity of the code you have to write.
Data binding has been around in various forms in different environments since early versions of tools like Visual Basic, FoxPro, and Delphi. Many early attempts at data binding left a lot to be desiredthey either exposed too many details to the programmer, provided inconsistent or unreliable behavior to the user, or were just too complicated to use and understand. Data-binding capabilities have been part of the .NET Framework for both Windows Forms and ASP.NET Web forms since version 1.0 of each. The data-binding capabilities of Windows Forms controls in .NET 1.0 and 1.1 were a big improvement over previous environments, but they still fell short in many situations. Significant improvements have been made in Windows Forms 2.0, making it both quicker and easier to get data-bound applications up and running.

Data-Binding Landscape

A number of things come into play to make data binding happen. First, you need the data. From the perspective of a presentation layer client application, this comes in the form of in-memory data sources. You need controls or components that are designed to work with that data to automatically present it and push changes back to the data source. This functionality may be encapsulated in the top-level controls that the user sees on the screen, reside in some intermediary component the acts as a middleman between a control type and a data type, or involve a combination of both the control and an intermediary component. If you will have multiple controls on a form that are all bound to the same data source and want those controls to behave as a unit, staying synchronized with changes to the underlying data source, you're going to need some support from the container of those controls to keep them all in sync. These mechanisms are all present in Windows Forms data binding.
You can use a variety of data sources to accomplish data binding in Windows Forms, such as data sets, custom collections, or individual business objects. You can bind those data sources directly to Windows Forms controls that are part of the .NET Framework, purchase third-party control libraries that support data binding, or write your own data-bound controls. Windows Forms 2.0 introduces a BindingSource component that lets you code complex data-binding scenarios with a lot lessand more maintainablecode. And the Form class itself also has built-in support to manage the synchronization of multiple controls on a form that are all bound to a single data source.

Data Sources

One thing you will need to keep straight as you read this book is the kind of data sources you are working with. You need to deal with several categories of data sources in a data-bound Windows Forms application, such as data sources that exist
·         At the data persistence layer or data tier, including relational databases, XML files, object storage mechanisms, and simple data files of some sort.
·         In the layers in your application, between the data persistence layer (e.g., database) and the data presentation layer (e.g., Windows Forms application), including objects and data structures in the services, and business and data access layers that your Windows Forms application works with. Layered application architecture is discussed later in this chapter and will be mentioned throughout the book; it is an important concept to make a part of your application development strategy.
<
4000
/a>·         In the Windows Forms application itself. This is the most important kind of data source that we will be focusing on in this book. The application may retrieve those data sources through other layers in your architecture, or it may obtain them directly from the database, through a service, or from files on disk.
Ultimately, data sources in the context of this book are objects in memory within the process of the Windows Forms application. These data sources present data to the user and are the sources users interact with through data-bound controls.

Data Objects and Collections

Data sources in a Windows Forms application are composed of object instances. A data source may be a single instance of a single object, or it may be a collection of object instances, where the collection itself is an instance of a container object. Those instances may be of almost any type, including types in the .NET Framework or types that you create as class or structure definitions. As a result, discussing data binding can get a little confusing, because you have to talk in generalized terms about the things that you are binding to. They may be a DataSet, an ArrayList, a BindingList<Customer>, a Customer, a Foo, or some unknown type that you program against through an interface reference without knowing the actual object type. Additionally, even once you get down to the individual object level, you need to describe the parts of that object that you are using for data binding, and those may be properties, fields, variables, or columns.
Throughout this book, I refer to an object as a data item if it's contained within some sort of collection that is being used for data binding. That may be an instance of a Customer class within a BindingList<Customer> collection, or it may be a DataRow within a DataTable within a DataSet. I refer to collections of objects as a collection or a list. However, to be used for many data-binding scenarios, a collection has to implement the IList interface to be properly described as a list.
The part of a data item being bound to could be a public property on an object instance, or it could be a column within a data row (also sometimes referred to as a field). For these situations, I use the term property, and if the collection is a data table, you can translate this to mean "the column within the data row that is the current data item."
You can think of a data member as a relative path to some piece of information within an object that contains data. If the object is a single instance of a data item, then the data member may just be the name of the property on the object that you want to use for data binding. For example, when you set up data binding to a TextBox control, you create an instance of the Binding class. The second parameter to the constructor is the data source, and the third parameter is the data member.

DataSets or Not, That Is the Question...

I refer to data sets (specifically, typed data set classes) extensively throughout the book. Chapter 2 covers how data sets work in more detail, but I want to briefly touch on them here to give an overview of how they will be used in this book. The use of data sets in Windows Forms applications is a topic that seems to incite heated debates throughout the .NET development community. Some people object to using data sets within the presentation layer because they assert that this couples your presentation tier to the data tier through the schema contained in the data set. They argue that you need to use custom business objects and collections in the presentation layer to make sure those objects are decoupled from the data tier schema. And depending on how you approach the use of data sets, they may be correct. But if you are smart about when, where, and how you use data sets, they can be a big time saver, help your application perform better, and make it easier to maintain.
You can completely decouple the data sets in your presentation layer from the actual schema in your data tier by defining the data sets that sit in between your presentation and data layers in the layers themselves. You can populate those data sets in your business layer or data access layer by iterating over the data retrieved from your data tier. You would have to do almost the same thing to populate a custom business object collection. By using data sets, you get
·         A highly functional container for data that can be strongly typed
·         Automatic change tracking for contained data
·         Seamless data-binding support
This doesn't mean that all of the examples in this book use data sets; numerous examples use custom business objects and collections for data binding as well. The mechanisms of Windows Forms support data sets and other kinds of objects equally. If you choose to use custom objects, you will be responsible for writing all of the code yourself to create those objects with the proper patterns and interface implementations to make them work correctly in data-binding scenarios. You will see in Chapter 9 that creating a rich container class for data items that approaches the functionality provided by data sets involves a great deal of work.
If you have a bias against data sets, you should take a look at .NET 2.0. A lot of the shortcomings of data sets in .NET 1.1, particularly with typed data sets, have been overcome in .NET 2.0. As demonstrated in the walkthrough earlier in this chapter, typed data sets give you a lot of power and let Visual Studio write thousands of lines of highly functional data access code for you with just a few simple drag-and-drop operations in the designer. With .NET 2.0, you can also work with data tables on their own without needing to create a data set to contain them.
If you aren't working with data sets, then the collections you work with will be instances of other types. You can and will most often use one of the rich container classes that are included in the .NET Framework. These include the types defined in the System.Collections namespace, which let you store any kind of object in a type-unsafe way and, even better, the generic collections defined in the System.Collections.Generic and System.ComponentModel namespaces, which allow you to define type-safe collections. In almost all cases in .NET 2.0, you should favor the generic collections over the type-unsafe versions in the System.Collections namespace.But you will see many simple examples before then that use the BindingList<T> generic collection class. You can also use the List<T> class for many data-binding scenarios, but BindingList<T> is a better choice in most cases for Windows Forms data-binding usage.If you need to, you can define your own collection classes and use them in data-binding scenarios.

What Is a Smart Client?

The subtitle of this book includes the term smart client, and it's that kind of application that I had in mind for most of the scenarios used in the examples throughout the book. As such, I think it is worthwhile to quickly define what constitutes a smart client application.
A smart client application is first and foremost a rich client application, or fat client, that runs on the user's desktop. This most often means a Windows Forms application in a .NET world, but it could also be a Visual Studio Tools for Office application, or it could be a smart device user interface. Smart client applications typically aren't standalone applications that run exclusively on the user's desktop; they are most often distributed applications, and the Windows Forms application is just the presentation tier portion of the application that communicates over the network to middle-tier application servers, Web services, or back-end databases.
Smart client applications often support offline use, allowing the application to still be useful when not connected to the network, or when the back-end servers of the application are unreachable, such as when using a laptop computer on an airline or in a customer's offsite location. Smart client applications can be most effectively operated if they support automatic deployment and update over the network, such as using the ClickOnce technology that is part of .NET 2.0 (and which is the topic of my forthcoming book in this series, written with Duncan Mackenzie). Finally, a smart client ideally runs under a constrained security context on the user's machine, and it prevents the smart client application from doing anything it wasn't designed to do, or anything that the user isn't willing to let it do based on who created the application or where it came from.
This book focuses on presenting data in a Windows Forms application and lets you interact with that data in a rich way. This is only a small slice of the architectural and technological considerations you need to master in order to develop a large-scale smart client application. To design and develop smart client applications, you will also need to become acquainted with distributed communications, data caching and synchronization, automatic deployment and update, and code access security. However, having a rich user interface is one of the most critical factors for moving to a smart client architecture successfully instead of just building Web applications. Learning how to build good data-bound interfaces will help you along the path to being able to build successful smart client applications.

The Quest for Type Safety

When you create a DataTable by loading a data set programmatically, from XML, or from a database query, the types of the columns are automatically specified, and the data set can use these column types for runtime type checking. However, the indexer on the DataRow class that lets you access the columns in a row is simply exposed as an Object reference. This means that your code can attempt to assign any type value to a column and there isn't any way the compiler can tell whether it will succeed or fail. You'll want to avoid this when you're developing code for a strongly typed platform like .NET. What you really want is for the compiler to be able to detect as many type incompatibilities as possible at design time, so that you don't ship a product that can blow up for improper casts or assignments.
To make a data set type safe, you basically have to wrap it in an API that is specific to each schema that you plan to put in it. This means writing a new class with strongly typed properties for all the tables and rows (the schema elements) for every data set you want to implement. Yuck! Who is going to bother to do that?
Well, the good news is that the code you need to write is a direct conversion of the data's schema, so it is a perfect candidate for code generation. The ability to generate a typed data set for any schema you want is part of Visual Studioit simply involves running either a command line tool or using some of the built-in designers in the Visual Studio environment.
Using Visual Studio 2005 to create a typed data set from a database generates more than just the typed data set; it also generates something new called a table adapter, which provides a type-safe way of populating the data set from the database. You will learn how to work with both typed data sets and table adapters in this chapter, and then you'll use these mechanisms for the bulk of th
a7d4
e data retrieval and update used throughout the rest of the book.
The other problem that typed data sets address is tied into the type safety aspect and resolves certain unsavory coding practices that untyped data sets induce.
If you believe in writing maintainable code, seeing hard-coded column and table names and/or indices like in this code example should make you nervousif the underlying schema changes, you have to hunt down all the places where the table and column names are used. If you use indices to get at the columns in a row, as the last line of code in this snippet does, the problem is even worse. At best, you can use find and replace, which is error prone and time consuming; often you will miss something, and you won't know about the problem until runtime. Hopefully your regression tests are comprehensive enough that any problems will be caught during test, but often differences between the actual schema and the hard-coded column names or indices aren't found until after the product has shipped.
Using typed data sets solves these problems. When you create a typed data set, code is generated that wraps the data set in a type-safe way by exposing tables and columns as strongly typed properties. If you program against those properties, the compiler will prevent you from assigning a value to a column that has the incorrect type. These properties also make sure you won't be trying to access a schema element that doesn't exist. If your schema changes, you simply regenerate the typed data set. If any of your code is trying to access parts of the schema that have been renamed or have gone away, you will get compilation errors instead of runtime errors. Tracking down disconnects with specific line information about what is broken will let you solve the problem much faster and reliably than with untyped data sets.
Another implicit benefit is that typed data sets expose the data set's schema through strongly typed properties and methods, and that enhances productivity. When you have a lot of different database entities, it gets difficult to remember the exact schema of the data you are dealing with. When you work with typed data sets, IntelliSense tells you exactly what the table names and column names are when you drill down to a row, and IntelliSense autocompletes those names when you're typing, so you don't even have to type them out yourself. These benefits of typed data sets help you develop code that works against the data set more quickly, which translates to cost savings.
The type information contained in a typed data set is also an enabler for design tools to make you even more productive. When you add a typed data set to a Windows Form, for example, the designer can reflect on that type to determine what tables are available, what the columns are within those tables, what their names and types are, what relationships exist between tables in the data set, and so on. Using that information, the designer and Properties window can provide you the ability to hook up common data-binding scenarios using only drag-and-drop and property grid interactions, and the designer will generate all the corresponding code. That translates to major productivity gains. As a result, you should always favor using typed data sets over untyped data sets, unless there is no way for you to have the schema information about what a data set will contain at design time.
Keep in mind that typed data sets have no effect on runtime data binding. The data-binding mechanisms of Windows Forms have to be type agnostic to work with any kind of data set or any object collection. You should still use typed data sets for the programmatic code type safety they provide, as well as the ability to use those data sets with the design-time features of Visual Studio, but ultimately they have no significant effect on what happens at runtime with data binding.