Geeks With Blogs

The Lanham Factor The (ir)rational thoughts of a (not-so)mad man

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 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?

Posted on Sunday, January 6, 2008 2:17 PM Cutting Code | Back to top

Comments on this post: To DataBind or Not To Databind...

# re: To DataBind or Not To Databind...
Requesting Gravatar...
I don't have an issue with databound controls, although I do get picky with *how* that data gets passed to the control.

I'm a huge fan of using Controller's and DTOs (Data Transfer Objects) within an application. This way you seperate out your domain from your UI, and you still provide the information that your UI needs to display the data.

Datasets are teh suck though.

Left by D'Arcy from Winnipeg on Jan 06, 2008 3:24 PM

# re: To DataBind or Not To Databind...
Requesting Gravatar...
I (ideally like to) use CSLA pretty exclusively It (the CSLA framework) has it's own databinding controls. Since CSLA is business process driven, not inheritance driven, my objects are developed for specific use cases.

So since in the use case I know what I am suppose to notify the user of (or display, or announce over the phone, or whatever 'notify' means), I don't have issues with 3rd/4th/5th normal form...all this denormalization/normalization has been handled by the business object when it was pulled from the database and business object and GUI follow the form of the use case.

Another advantage is that since the databinding in .NET (and CSLA framework which are made from .NET databinding control roots) controls now-a-days allow updates/adds/deletes through them [since the business objects just aren't stupid DTO's that just hold raw data] I don't need to worry about the GUI developer (or the person who inherits the application) calling special methods to check authorization issues when a user want to add/update/delete and I don't have to worry about the composer of the GUI (or next developer) knowing to call certain BLL methods in order to update/add/delete a row in a GridView/DetailsView/FormView, or some custom page - whatever - in all cases they just call Save(). They should of course wrap in a try/catch for a ValidationException or check the IsValid property before doing anything...but that's in the developer's also a CSLA SOP - so another CSLA developer already knows this.

Yes, CSLA ROCKS in on my boxers...but you asked what we use, or like to use...and that's what I like to use.
Left by Brian Johnston on Jan 06, 2008 8:03 PM

# re: To DataBind or Not To Databind...
Requesting Gravatar...
I use the ObjectDataSource and have been pretty happy with it.

I have not figured out a good way to edit many to many relationships declaratively though. I still have to write UI binding code for that.

On the winforms side databinding is really cool when you implement the INotifyPropertyChanged interface on you business objects and use the IBindingList interface for your business collections. When properly implementing those interfaces when you programmatically change values or add/ remove itmes form your collections the UI gets updated auto-magically.
Left by Aaron Carlson on Jan 06, 2008 8:08 PM

# re: To DataBind or Not To Databind...
Requesting Gravatar...
I, too, have a lot of issues with databound controls. My experiences, though limited, have been (shockingly) similar to yours, and my preference is to avoid declarative databinding. I just think it's too limited to be useful all the time, and it's really annoying when trying to troubleshoot problems.

I sometimes use a hybrid approach for binding data. To bind to a DataGrid, I just define the bound columns in the markup, and then do all the wiring in the code behind. Technically, it's "DataBinding", because I'm using the DataSource property and the DataBind() method in my "wiring" code... But, because I'm not really using it for updates to my business objects, I have the flexibility to make the CRUD stuff happen however I want. Once my updates have occurred, I just "re-wire" everything.
Left by Bret on Jan 11, 2008 4:11 PM

# re: To DataBind or Not To Databind...
Requesting Gravatar...
CSLA binding is really terrible. It has TONS of issues and Lhotka has some "hacks" called EditLevels that will drive you nuts trying to figure out. Unless all your data is on one form and no child windows, you will have lots of issues. He needs to re-write data binding and fix his EditLevel mismatch hell.
Left by Mike Moore on Nov 10, 2008 12:48 PM

Your comment:
 (will show your gravatar)

Copyright © Brian Lanham | Powered by: