I've been playing around with assigning an ASP.NET WebControl's DataSource when I'm handling its DataBinding event. For general data binding logic in my pages, it seems to work well in organizing things.
What arguments are there for not doing this?
I've been playing around with assigning an ASP.NET WebControl's DataSource when I'm handling its DataBinding event. For general data binding logic in my pages, it seems to work well in organizing things.
What arguments are there for not doing this?
Just off the top of my head, I would argue against doing this for two reasons:
1) The design smells 2) It obscures what's really happening
For #1, I say this because in order to handle its databinding event, it has to have begun binding to something already. To change what it's binding to in mid-stream isn't what I would call an ideal design.
This leads to #2, in that if someone creates one of your controls, and calls .DataBind() on it, and it internally starts binding to something else, it's entirely unclear to the caller what's going on.
While I haven't looked at it from a technical perspective, it seems to me that you'd be raising the possibility of a recursive databinding infinite loop as well. I guess I'd really need to see some code to tell if what you were doing was acceptable, or if there were better ways of doing it.
Honestly, what arguments are there for doing this?
If you want to use the same datasource for other WebControl's on that same page, or reference components of that datasource within the page's code behind, you'll have to re-create the datasource yet again. Essentially, you'll be creating two instances of the same object.