لطفا منتظر باشید ...
Introducing Data Binding
Traditionally, data binding has been viewed with a great deal of suspicion. Many developers feel that it's an inflexible, clumsy tool favored by beginning programmers. For the most part, they have been right.
Data binding usually suffers from several well-known problems:
It's inflexible. For example, you can only bind special controls to special objects—and when you do, you usually lose control of the process. In many cases, you need to either enable or disable features like data editing completely, as data controls don't allow you to participate in their work.
It's ugly. When you bind to data, you often have to display all available rows, and sacrifice any ability to format details like column widths or order. And if you hoped to convert a field made up of numeric constants into a friendlier representation, forget it.
It's fragile. Data binding doesn't follow classic three-tier design. Instead, it binds database details directly to user interface logic. If the data source changes, or you need to create functionality that should be shared among different applications or environments, you are entirely on your own.
It's proprietary. A fine-tuned data binding solution is great—until your organization decides to upgrade to a newer programming tool or change programming languages. At this point, there is generally no migration path, because much of the logic is hard-coded in proprietary designer or project files.
.NET provides some remarkable data binding enhancements that just might change your mind. The first two obstacles—lack of flexibility in programming and display—are completely removed and replaced with an elegant, extensible framework. The questions of application design and proprietary standards may still apply, depending on your goals. Certainly, .NET allows programmers in several different languages to share components and classes, but heavy use of data binding still makes it extremely difficult to port your code to a non-Microsoft platform.
