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.


  • Hey Bertrand, move on blogs.dng ;-)

  • Thank you so much for this comment, Alister, I really appreciate. So, when are you getting a blog?

  • Bertrand: The way I see it, there's actually two separate issues here: 1) does the control persist as markup on the page, and 2) is the control displayed on the visual design surface, along with "visual" controls.

    Personally, I think that the notion of a separate area where non-visual elements are displayed (even if they actually "live" as markup on the page) is a useful one. Putting them on the visual design surface strikes me as potentially confusing. Where should they go? Does it matter where they live on a page? Where do you shove them so they don't interfere with your visual layout (especially in a flow layout, where they occupy space in the flow and change the layout of the page)? Fortunately, I see that Whidbey has an option to hide non-Visual controls - but of course then it's not obvious that they exist at all, and if you unhide them, it reflows your page.

    I do see your point about the data-source-in-a-template case, although it seems like there could be another solution. I'll have to think about that one... ;)

    Side question - how does one flag a control as non-visual in Whidbey?

  • Kevin: It doesn't matter where you put a data source on a page as long as you don't need it inside some container, so I'd put them at the end of the page so that they don't disturb the rest of the visual layout.

    To make a control non-visual, just mark it with the [NonVisualControl] attribute...

  • Bertrand: Yes, I realize that. My point was that rendering the non-visual controls inline in the page forces the page designer to be aware of and accomodate those issues. Personally, I would rather just see the non-visual controls down in the tray. But that's just my opinion.

    Thanks for the NonVisualControl pointer.

  • I have to say that I second Kevin. Having the non visual controls in the flow is really annoying.

  • This kind of choice is not made whimsically. It relies on usability studies, which means that while some may find it annoying, most people like it better this way.

    As you have an easily discoverable designer option to make non-visual controls appear and disappear at will, I don't think there's much more we can do...

Comments have been disabled for this content.