The Lanham Factor

I have generally avoided the databound controls provided by the .NET framework.  I am referring specifically to controls such as the GridView.  Oh don't get me wrong, I use the GridView like I use oxygen.  I just don't use an associated DataSource control.  Utlimately, therefore, I manually bind controls to data.  There are three main reasons I have opted to avoid databound

1. Distributed Applications - Most of the business applications I design incorporate a business layer so it is rare that I bind directly to a relational database. 
   1. Response - .NET 2.0 responded to this with the ObjectDataSource.  The ObjectDataSource is wickedly powerful.
2. Data Normalization - Most of the business applications I design utilize data sources in at least 3rd normal form and sometimes even in 4th normal form.  I must confess that the practicality of 5th normal form eludes me.
   1. Response - I have to admit that I am still unsure as to the best way to handle relational data in databound controls.   Shame on me, I suppose, but this is the point I am trying to make.
3. Debugging - My #1 absolute biggest hatred of declarative programming is the (in)ability to debug. 
   1. Response - .NET 2.0 offers the ability to trap events and process exceptions only.  Basically, this allows you to trap and event, check for exceptions and, if no exception occurs, let the DataSource control do its thing.

Recently I had occasion to build a small application under extremely tight time constrants.  As such, I decided to use databound controls.  I found that it isn't that bad.  I did run into normalization and debugging issues (as described above) but overall I had a generally positive experience.

I went on to write a small file sharing application over the holidays.  I decided once again to rely on databound controls.  I did find certain situations where programming the databound controls was simply too complicated and time consuming for me.  In those situations, I opted for some good ol' fashioned coding. 

My recent experiences are making me rethink the databound controls.  I am finding that in some situations it is very useful and appropriate.  I am also finding that in other situations I shouldn't feel forced to stick with them.

There are some problems with this, of course.  One is that the application will be a mix of databound and non-databound controls.  So when someone comes along to maintain it they might be wondering "Why did you...here...and there you....what the?"  That's why should always always always rely on best practices.

1. Proper Design - A good design (based, of course, on proper requirements) will allow you to implement each feature in the most appropriate way.
2. Coding Standards & Guidelines - These will dictate appropriate situations for both implementation techniques and can help alleviate some of the confusion caused by a mixed application.
3. Enterprise Architecture - Part of the enterprise architecture is to help define the de facto implementation techniques for applications.  That's not to say you are forced to use that technique.  However, it is to say "when in doubt, do this."  This helps promote consistency among implementations.

So, as usual, I am going to ask you.  Do you use databound controls or not?  What is your opinion?  What are your general experiences?