Do data source controls belong on the page?
I get a lot of feedback on this subject (see this post if you have time for example). More and more developers are now finally getting the multi-layered application architecture concept, which is a great improvement over the situation we had even five years ago. So many of them, the first time the see data source controls on the page, go WTF is this doing in my UI layer? Even though the ObjectDataSource is here to make them feel better about it.
Well, first of all, in ASP.NET, the Page is not the UI layer exactly. It contains the UI (the Template View, that is, the CodeFront), but it also contains some form of controller or rather Page Controller (see Martin Fowler's Patterns of Enterprise Application Architecture). So it's actually more an application surface than a simple UI surface.
But it is also wrong to see the CodeFront as the UI and the CodeBehind (or CodeBeside) as the controller. You should see it more as the declarative part and the procedural part of the same object.
So what did we have in v1? To bind a control to data, you had to do it from the procedural part of the page. If you were doing it quick and dirty, you were instantiating a Connection, a Command or DataAdapter, and filling a DataSet or DataReader with it. Then, you would attach this DataSet or DataReader as the data source of your controls and call databind. If you were doing multi-layered development, you were instantiating objects and binding them to the controls in pretty much the same way. It should be noted at this point that if you wanted to prototype a quick-and-dirty page and then migrate this to a multi-layered page later, you had to rewrite a large part of this boilerplate code. The designer made all this a little more confusing by displaying some of the procedurally defined components on the designer surface despite the fact that they were nowhere to be seen in the CodeFront markup.
As framework developers, every time we see code that's copied all over any application with little variations, we have to ask ourselves if we couldn't make it declarative.
And that's what data source controls are: a declarative way to bind controls to data. Is anyone shocked by the presence of jsp:useBean tags in a JSP page? Well, you shouldn't be any more shocked by the presence of a data source control in an ASP.NET page. On the other hand, what's wrong is procedural code in the declarative part, and you should avoid this as much as possible (it is IMHO a great design flaw in JSP to define procedural markup).
By going from the procedural part to the declarative part, the data-binding code did not change layers, it just migrated to a different part of the same object.
The end result is improved productivity as you don't have to rewrite all this boilerplate code. You will also quickly notice that the migration from quick-and-dirty SqlDataSource to an ObjectDataSource is really easy as there is no source-specific code. All the visual controls see is a data source, they don't have to know where the data came from. All you have to really change is the data source itself.
But the data source controls have additional advantages. My favorite are parameters. You can add parameters to any data source. These parameters will allow you to declaratively filter the source's data according to a query string parameter, a form field, a control value or an arbitrary object value. Having a DropDownList filter the contents of a DataGrid has never been so easy: you can have such a page without writing a single line of code.
I'm currently writing a web site with Whidbey, and my goal is to have zero code in the web site project itself. It features declaratively interchangeable data stores and a fully skinnable UI. Having zero code in the web site is not a contrived exercise, it's actually promoting good design and the good news is that it's amazingly easy to do in ASP.NET v2.
So I'll say it loud and clear: ASP.NET 2.0 promotes good design.