The DataSource Control

[Angel]

One claim made of aids in rapid application development but all I see is
people having trouble with it and asking lot's of questions about it. I do
not claim that these controls are not useful but they are not certainly the
end game. In fact, I consider it only one more tool in the toolbox and not
necessarily all that significant.

I can write application just as rapidly and with less constrains using code.
It takes me just three lines of code to bind my databound controls and I am
in full control of what is going on.

I just help someone on this forum which had an issue which, in my opinion,
would not happen if the developer had use code and learned what they were
doing in the first place. The danger with these so-called RAD controls is
that they tend to hide too much. Also make decision that limit how and what I
can do. Invariably the developer ends up writing tons of work-around code
(some necessary and some unnecessary) in order to coarse the controls to
behave or be compatible with their existing business logic or other
interfaces.

It has to make you wonder… We should be pushing knowledge not quick
solutions! Leave the Easy button to those other guys.

So my question is – How exactly does the DataSource Control promotes Rapid
Application Development?

There is an old saying:

You pays me now… or you pays me later. And from my vantage point what the
Datasouce control gives in one instance it takes away later when a real world
issue comes into play. This very forum is replete with developer seeking
help because they get to a point where the easy and fast approach caught up
with them.

 

[Phil H]

One claim made of aids in rapid application development but all I see is
people having trouble with it and asking lot's of questions about it. I do
not claim that these controls are not useful but they are not certainly the
end game. In fact, I consider it only one more tool in the toolbox and not
necessarily all that significant.

I can write application just as rapidly and with less constrains using code.
It takes me just three lines of code to bind my databound controls and I am
in full control of what is going on.

I just help someone on this forum which had an issue which, in my opinion,
would not happen if the developer had use code and learned what they were
doing in the first place. The danger with these so-called RAD controls is
that they tend to hide too much. Also make decision that limit how and what I
can do. Invariably the developer ends up writing tons of work-around code
(some necessary and some unnecessary) in order to coarse the controls to
behave or be compatible with their existing business logic or other
interfaces.

It has to make you wonder... We should be pushing knowledge not quick
solutions! Leave the Easy button to those other guys.

So my question is - How exactly does the DataSource Control promotes Rapid
Application Development?

There is an old saying:

You pays me now... or you pays me later. And from my vantage point what the
Datasouce control gives in one instance it takes away later when a real world
issue comes into play. This very forum is replete with developer seeking
help because they get to a point where the easy and fast approach caught up
with them.

The purpose of the DataSource controls introduced in version 2 of
ASP.NET is to save a lot of laborious and repetitive code writing, not
to supplement a lack of knowledge on the part of the developer.

I am inclined to agree that these controls are not always appropriate
given that their behaviour will not meet actual requirements in some
cases. It is important to properly understand how these controls work
and how to configure them. That way the developer can make informed
choices about when and how to use them.

I disagree with the suggestion that they are for the novice or only
for those who want quick solutions. If you take that to its logical
conclusion we should all be writing in assembly language and not be
pampered with high level languages and the luxury of object oriented
code.

There are alternatives to the Datasource controls that are seldom
mentioned on this forum, that can be equally powerful in circumstances
where programmatic control is needed, namely the Dataset objects that
are created and stored in the App_Code folder as xml encoded files.
They are only for data sources that support SQL but can save a lot of
effort writing code to construct Command, Connection and DataReader
objects to access SQL databases. I recommend readers to look them up
and study them as well as the Datasource controls.

 

[Angel]

I am afraid that my message is not clear. So let’s start with suggestion
that the datacontrols are for newbie. That could not be further from the
truth. I believe the help you get something done quickly. Something like
taking the stairs or the elevator which one would you take? My answer it
depends, how many stories up I am going? But if you install the elevator and
close off the stairs, I will be pissed.

My gripe with the declarative model is that in general is that it is being
pushed to the exclusion of all else. I wanted to setup the DetailsView
control using DataSource instead of add a Datasource control and I could not
find anything at all. I took days of my time searching the internet to piece
together enough information to do a simple thing like bind a DetailsView
control. You get a lot more help if you use the DataSource Controls from
all sources. I am not saying that the information is not there, just that
it is not easy to get to. That’s my gripe.

Secondly, there are a number of situations where the declarative approach
will work, mostly dynamic creation of columns or fields. In addition, the
DataSource control tends to make things flat and promote spaghetti code.
Note, I did not say the DataSource implementation is spaghetti code but they
do tend to make the programmer lazy and sloppy so that the work tends to
become spaghetti code. I see this all the time. They also tend to add what
I call cognitive weight which tends to overload the brain and eventually
overwhelm the programmer. It should have been encapsulated into the
individual controls that use it and made a component not a control. Or if you
will an extender and should have been managed by a wizard at grid or
detailsview or whatever level not as a separate entity.

Thirdly, exactly how are we better off? I see no real advantage in using
these controls over the old approach. At least not for the amount of pain
they cause. I am sure that you could site one example where you state their
superiority and would probably counter with what I think is a better
solution. I guess what I am saying if I may go back to the elevator analogy—
you have provided me with an elevator with no power and given me a set of
bicycle pedals so I can power the elevator! Heck, I’ll use the stairs,
Thanks.

These controls and the declarative model are not a complete solution. Not
by any means so why are you getting ready to deprecate the old when you have
not gotten your act together with the new? That’s my Gripe and That’s my
message.