DataSource Controls and Declarative Programming

As an example, DataGrid was capable enough to build a table, render it, and handle button clicks, and that's about it (I say that since I implemented it). To do anything more, one had to handle appropriate events and tell it what to do next. In a sense, it had hit a ceiling... and page code was its out. From that perspective, DataSource controls are just a new out. The grid can talk to it, and intelligently take the next step to provide default behavior for those 90% cases. Of course being a framework, we did provide a whole slew of events to allow one to change the default behavior as well as preserved the v1 model.

With the smarter controls (controls that understood the page lifecycle, its events, and state management, and could fully utilize the underlying infrastructure), we added features like declarative parameters, transparent data caching, server-side paging ability, hierarchical data support, and ability to work asynchronously (ok, the last one is just architecture... we don't have any built-in async controls). These features would require much more code than simply calling DataBind.

Are DataSources simply an abstraction over a DataSet? I wouldn't say so. I think they are a simple abstraction for data access, i.e. for getting data into the UI tier, and pushing changes back into the data tier, independent of the actual storage.

Are data sources a quick and dirty tool that break the n-tiered model? Again, I don't think so. ObjectDataSource illustrates using data sources while keeping data access and business logic separate from UI. The model doesn't prevent one from writing a DataSource that works against a custom data access layer. The SqlDataSource is just one of many tools in the ASP.NET toolbox, and should be used when it is the right thing for the job. The point is, a DataSource control simply exists as a counterpart to the DataBound control so the latter can work intelligently.

Declarative programming model
I am a believer in this. I see markup as the new code albeit a more designable form of code. Wire-up glue shouldn't have to be expressed in code (atleast for mainline scenarios). I'd like to see a model where components encapsulate behavior and patterns, and are wired together declaratively (might even make MVC approachable!). Yes, there is still code... in fact, lots of it... in components and in the framework. I am a developer myself. :-)

I am particularly interested in comments on the subject of declarative programming. I know Whidbey is just a start, and more needs to happen before it becomes a real "programming model." But can it become real and capable of covering most of the typical application scenarios? Thoughts?