Jean Paul Understands

{

After listening to the .NET Rocks podcast he was on covering Test Driven Development, I glanced at his blog and saw this post/rant against declarative databinding. Since the Visual Basic 5 Form Data Wizard, a lot of this automated stuff has remained beyond my liking. Well, actually that VB 5 Form Data wizard did work out really well once: I had a meeting with a client and nothing to show so it bailed me out that time...

Here are my big problems with declarative databinding:
1. When does it happen?
I have no idea based on the demos. You set things up at design time and run the app after which you're supposed to smile and think that it's cool, but databinding for me in the "real world" never seems to happen that way. Sometimes binding is conditional or based on circumstances that can only be evaluated programmatically. Not only that, but sometimes I'm binding many many things (think 10 dropdown lists) and don't want a data source control for each one.

2. Embed SQL statements in the ASP.NET Page?
Never, ever, ever. Usually stuff like this is tucked in the business layer with a stored procedure. I like the idea of object data sources, but it seems like a lot of work for the small stuff, like lookup values.

3. It's never that simple.
Like the last project I worked on, in which some fields displayed in a grid were too long, so I had to iterate bound data and make tooltips. Or the column that's an encoded link based on some data outside of the grid. Or the column that displays various images based on some criteria (think: sometimes a PDF icon, sometimes a Word doc icon, and so on).

Don't get me wrong at all: databinding is good and I use it every day. Declarative databinding, however, has never proved useful to me.

}