When should I be cautious using data binding in .NET?

Question

I just started working on a small team of .NET programmers about a month ago and recently got in a discussion with our team lead regarding why we don't use databinding at all in our code. Every time we work with a data grid, we iterate through a data table and populate the grid row by row; the code usually looks something like this:

Dim dt as DataTable = FuncLib.GetData("spGetTheData ...")
Dim i As Integer

For i = 0 To dt.Rows.Length - 1 '(not sure why we do not use a for each here)'
  gridRow = grid.Rows.Add()
  gridRow(constantProductID).Value = dt("ProductID").Value
  gridRow(constantProductDesc).Value = dt("ProductDescription").Value
Next

'(I am probably missing something in the code, but that is basically it)'

Our team lead was saying that he got burned using data binding when working with Sheridan Grid controls, VB6, and ADO recordsets back in the nineties. He's not sure what the exact problem was, but he remembers that binding didn't work as expected and caused him some major problems. Since then, they haven't trusted data binding and load the data for all their controls by hand.

The reason the conversation even came up was because I found data binding to be very simple and really liked separating the data presentation (in this case, the data grid) from the in-memory data source (in this case, the data table). "Loading" the data row by row into the grid seemed to break this distinction. I also observed that with the advent of XAML in WPF and Silverlight, data-binding seems like a must-have in order to be able to cleanly wire up a designer's XAML code with your data.

When should I be cautious of using data-binding in .NET?

Answer 1

You should be cautious when using anything you don't understand fully.

I'll confess to not understanding data-binding very well, but I still think your team lead's position is a little extreme and reactionary.

My rule of thumb would be; don't rely on something till you understand it. Once you understand it, you don't need my (or anyone elses) rules of thumb.

:)

Some links related to caveats using data-binding:

http://travisgosselin.com/blog/?p=46

http://stackoverflow.com/questions/450373/databinding-in-c-and-net

Answer 2

As everything else, you can use it properly, or improperly. DataBinding can be very powerful at times, but like mentioned before, you must know how to use it correctly.

Generally, there are two types of binding in .NET (and its tools): automatic and manual. Automatic binding is when VS creates everything for you, and you drag-and-drop. Don't do this. EVER. Only exception for this would be these new additions to Silverlight 4 in VS2010. It is the only automatic binding done properly.

On the other hand, manual databinding using DataSets as Unit of Works, CurrencyManagers and other stuff, can be extremely useful (talking about .NET 2.0 WinForms here, right? ).

Answer 3

http://www.knowdotnet.com/articles/differences.html

things have changed dramatically FOR THE BETTER in .Net

Data Binding vs Manual Population

VB6 programmers have stayed away from the ADO data control and bound controls because of some performance reasons. I am making the move towards VB.NET and have the feeling that bound controls are not so evil after all.

Answer 4

If all you are doing is displaying data, in my opinion, there is no reason NOT to use databinding.

I too come from the VB6 world, where databinding bit us again and again, so we had standards and workarounds in order not to use it.

Enter .NET, where databinding is as flexible as you need it to be. I have come to really appreciate the power that binding has now.

You are writing much unnecessary code by rejecting the built in capabilities.

You can even bind on-screen objects such as textboxes to properties in classes. Check out this link for an overview of winforms databinding. http://msdn.microsoft.com/en-us/library/ef2xyb33(v=VS.100).aspx