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.