Do you use the new datasource controls?

[Alan Silver]

Hello,

SHORT VERSION OF THE QUESTION...
What is your experience of the new ASP.NET datasource controls? Are they
as good as they look, or are they another useless gimmick for doing
flashy management demos?
LONG VERSION OF THE QUESTION...
When I started programming with Visual Basic 6, there were some (new I
think) features that were supposed to be the bee's knees in saving the
programmer time. These included data bound controls and the data
environment (DE). When you went through the demos, you came away very
impressed at how easy it was to produce db-driven applications. For
data-bound controls, you just added an ADODC control to the form, then
bound the other controls to that. With the DE, you used a graphical tool
in the IDE to connect to the db, then drag the required fields onto the
form. Wonderful stuff.

This state of bliss lasted as long as you were just playing. When you
started your first real application, you discovered that they weren't
quite as good as you thought. There were various quirks and oddities
that meant you had to write extra code to avoid being trapped by the
system. After a while, you realised that you were fighting the
environment to persuade it to do what you wanted. You began to wonder if
it was worth it. The amount of code required to do anything useful
exceeded the amount you would have written had you done the whole thing
by hand.

In desperation, you posted a message to Usenet (or did a search if you
were a Good Netizen) and you discovered that these toys were for show
only. Real Programmers didn't use them. In fact, Real Programmers said
fairly rude things about them!! So, after investing ages building your
new app around them, you had to scrap them and write it all from
scratch.

My first thought when I saw the new ASP.NET data controls was that they
were a brilliant time-saver. My (immediate) second thought was that they
could easily be the same scenario all over again.

So, anyone any comments? Are they really as good as they look, or has MS
done the same trick again? I don't want to waste time with them if they
are going to be a problem, but it will be worth it if they are as useful
in real life as they appear to be from the simple examples shown in the
books and articles.

Comments please.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Karl Seguin]

SqlDataSourceControl and XmlDataSourceControl (and whatever else there is
except for the ObjectDataSource control) is the biggest step back from
tiered programming introduced in ASP.Net 2.0

I don't have any problems with them being there, but it's how they are
always explained so shallowly. MS needs to do a better job of explaining
good coding vs marketting stuff.

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
http://openmymind.net/redirector.aspx?documentId=51 - Learn about AJAX!

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:3L**************@nospamthankyou.spam...

Hello,

SHORT VERSION OF THE QUESTION...
What is your experience of the new ASP.NET datasource controls? Are they
as good as they look, or are they another useless gimmick for doing flashy
management demos?
LONG VERSION OF THE QUESTION...
When I started programming with Visual Basic 6, there were some (new I
think) features that were supposed to be the bee's knees in saving the
programmer time. These included data bound controls and the data
environment (DE). When you went through the demos, you came away very
impressed at how easy it was to produce db-driven applications. For
data-bound controls, you just added an ADODC control to the form, then
bound the other controls to that. With the DE, you used a graphical tool
in the IDE to connect to the db, then drag the required fields onto the
form. Wonderful stuff.

This state of bliss lasted as long as you were just playing. When you
started your first real application, you discovered that they weren't
quite as good as you thought. There were various quirks and oddities that
meant you had to write extra code to avoid being trapped by the system.
After a while, you realised that you were fighting the environment to
persuade it to do what you wanted. You began to wonder if it was worth it.
The amount of code required to do anything useful exceeded the amount you
would have written had you done the whole thing by hand.

In desperation, you posted a message to Usenet (or did a search if you
were a Good Netizen) and you discovered that these toys were for show
only. Real Programmers didn't use them. In fact, Real Programmers said
fairly rude things about them!! So, after investing ages building your new
app around them, you had to scrap them and write it all from scratch.

My first thought when I saw the new ASP.NET data controls was that they
were a brilliant time-saver. My (immediate) second thought was that they
could easily be the same scenario all over again.

So, anyone any comments? Are they really as good as they look, or has MS
done the same trick again? I don't want to waste time with them if they
are going to be a problem, but it will be worth it if they are as useful
in real life as they appear to be from the simple examples shown in the
books and articles.

Comments please.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Edwin Knoppert]

I just reqrote my app from AccessDataSource to SqlDataSource.
Works identical but it's properties are much better.
ADS uses datafile and thus you had to declare an appsetting as well.
The SqlDS can use the connection string directly!
Much better.

Like:

<asp:SqlDataSource ID="SqlDataSource1" runat="server"
ConnectionString="<%$ ConnectionStrings:Mydsn %>"
ProviderName="<%$ ConnectionStrings:Mydsn.ProviderName %>" >
</asp:SqlDataSource>

Now i have only one connectionstring declared.
The .update() and so worked the same as before.
"Alan Silver" <al*********@nospam.thanx> schreef in bericht
news:3L**************@nospamthankyou.spam...

Hello,

SHORT VERSION OF THE QUESTION...
What is your experience of the new ASP.NET datasource controls? Are they
as good as they look, or are they another useless gimmick for doing flashy
management demos?
LONG VERSION OF THE QUESTION...
When I started programming with Visual Basic 6, there were some (new I
think) features that were supposed to be the bee's knees in saving the
programmer time. These included data bound controls and the data
environment (DE). When you went through the demos, you came away very
impressed at how easy it was to produce db-driven applications. For
data-bound controls, you just added an ADODC control to the form, then
bound the other controls to that. With the DE, you used a graphical tool
in the IDE to connect to the db, then drag the required fields onto the
form. Wonderful stuff.

This state of bliss lasted as long as you were just playing. When you
started your first real application, you discovered that they weren't
quite as good as you thought. There were various quirks and oddities that
meant you had to write extra code to avoid being trapped by the system.
After a while, you realised that you were fighting the environment to
persuade it to do what you wanted. You began to wonder if it was worth it.
The amount of code required to do anything useful exceeded the amount you
would have written had you done the whole thing by hand.

In desperation, you posted a message to Usenet (or did a search if you
were a Good Netizen) and you discovered that these toys were for show
only. Real Programmers didn't use them. In fact, Real Programmers said
fairly rude things about them!! So, after investing ages building your new
app around them, you had to scrap them and write it all from scratch.

My first thought when I saw the new ASP.NET data controls was that they
were a brilliant time-saver. My (immediate) second thought was that they
could easily be the same scenario all over again.

So, anyone any comments? Are they really as good as they look, or has MS
done the same trick again? I don't want to waste time with them if they
are going to be a problem, but it will be worth it if they are as useful
in real life as they appear to be from the simple examples shown in the
books and articles.

Comments please.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>SqlDataSourceControl and XmlDataSourceControl (and whatever else there is

except for the ObjectDataSource control) is the biggest step back from
tiered programming introduced in ASP.Net 2.0
Why specifically? I suspect that the answer to that question may be at
the heart of what I was originally asking.
I don't have any problems with them being there, but it's how they are
always explained so shallowly. MS needs to do a better job of explaining
good coding vs marketting stuff.

And you consider these to be marketing stuff? That's how most VB6
programmers seemed to view the DE and data-bound controls. I'm just
interested to know why you don't like these, and what specific problems
you had.

I think I can probably guess the answer, but I would like to hear it
from someone who has experience.

Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>I just reqrote my app from AccessDataSource to SqlDataSource.

Works identical but it's properties are much better.
OK, but that's going from one datasource to another. I was more
wondering about the value of the datasources altogether. Sure they look
very enticing, but so did the data environment and data-bound controls
in VB6. I don't want to waste time and energy on something that will be
discarded as another useless gimmick in a few weeks/months.
ADS uses datafile and thus you had to declare an appsetting as well.
The SqlDS can use the connection string directly!
Much better. <snip>Now i have only one connectionstring declared.
I only have one connection string declared anyway!! I have had only one
connection string per site for years, way back in the old ASP days. That
itself isn't an improvement.

Thanks for the reply. I would be interested to hear if you have had any
problems using datasources in general, especially when it comes to
complex sites.

TA ra
The .update() and so worked the same as before.
"Alan Silver" <al*********@nospam.thanx> schreef in bericht
news:3L**************@nospamthankyou.spam...

Hello,

SHORT VERSION OF THE QUESTION...
What is your experience of the new ASP.NET datasource controls? Are they
as good as they look, or are they another useless gimmick for doing flashy
management demos?
LONG VERSION OF THE QUESTION...
When I started programming with Visual Basic 6, there were some (new I
think) features that were supposed to be the bee's knees in saving the
programmer time. These included data bound controls and the data
environment (DE). When you went through the demos, you came away very
impressed at how easy it was to produce db-driven applications. For
data-bound controls, you just added an ADODC control to the form, then
bound the other controls to that. With the DE, you used a graphical tool
in the IDE to connect to the db, then drag the required fields onto the
form. Wonderful stuff.

This state of bliss lasted as long as you were just playing. When you
started your first real application, you discovered that they weren't
quite as good as you thought. There were various quirks and oddities that
meant you had to write extra code to avoid being trapped by the system.
After a while, you realised that you were fighting the environment to
persuade it to do what you wanted. You began to wonder if it was worth it.
The amount of code required to do anything useful exceeded the amount you
would have written had you done the whole thing by hand.

In desperation, you posted a message to Usenet (or did a search if you
were a Good Netizen) and you discovered that these toys were for show
only. Real Programmers didn't use them. In fact, Real Programmers said
fairly rude things about them!! So, after investing ages building your new
app around them, you had to scrap them and write it all from scratch.

My first thought when I saw the new ASP.NET data controls was that they
were a brilliant time-saver. My (immediate) second thought was that they
could easily be the same scenario all over again.

So, anyone any comments? Are they really as good as they look, or has MS
done the same trick again? I don't want to waste time with them if they
are going to be a problem, but it will be worth it if they are as useful
in real life as they appear to be from the simple examples shown in the
books and articles.

Comments please.

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Karl Seguin]

Well, I cringe when I see a button's click event open op a connection,
create a command and populate a dataset. The code because totally
un-reusable. It's fine for my dad's website, but not for the enterprise
architecture I'm building, which will eventually need to have a web service.
The code in the button click should be quite deeper, it should be
encapsulated in a data access layer and exposed via a rich business layer.
By doing so, I've increased my testability (unit tests on business and data
layers are easier than presentation layers), my reusability and
maintainability (oh geez, who would have though saving a product begins in
the Product class!).

Instead of promoting rich tiering, the XXXDataSource actually thin the tiers
even more. I thought doing database work in the button's click was bad, now
people are doing it in HTML.

I don't consider the features themeselves to be marketting, but the way they
are talked about is. It's all about saving you 70% time. The truth is that
while it might save you time in some projects (prototyping), it'll cost you
much much more in others - no one ever says that. There needs to be more
guidance about prudent usage, otherwise it IS marketting. Arm developers
with unbiased and real information, build up their knowledge and they'll be
able to understand a problem and find the right solution. Teach a man how
to fish as it were...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:9C**************@nospamthankyou.spam...

SqlDataSourceControl and XmlDataSourceControl (and whatever else there is
except for the ObjectDataSource control) is the biggest step back from
tiered programming introduced in ASP.Net 2.0

Why specifically? I suspect that the answer to that question may be at the
heart of what I was originally asking.

I don't have any problems with them being there, but it's how they are
always explained so shallowly. MS needs to do a better job of explaining
good coding vs marketting stuff.

And you consider these to be marketing stuff? That's how most VB6
programmers seemed to view the DE and data-bound controls. I'm just
interested to know why you don't like these, and what specific problems
you had.

I think I can probably guess the answer, but I would like to hear it from
someone who has experience.

Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>Well, I cringe when I see a button's click event open op a connection,

create a command and populate a dataset. The code because totally
un-reusable. It's fine for my dad's website, but not for the enterprise
architecture I'm building, which will eventually need to have a web service.
The code in the button click should be quite deeper, it should be
encapsulated in a data access layer and exposed via a rich business layer.
By doing so, I've increased my testability (unit tests on business and data
layers are easier than presentation layers), my reusability and
maintainability (oh geez, who would have though saving a product begins in
the Product class!).

Instead of promoting rich tiering, the XXXDataSource actually thin the tiers
even more. I thought doing database work in the button's click was bad, now
people are doing it in HTML.
OK, that all makes sense, but let's assume for a moment that the stuff
actually works properly. If so, then why do you need to have the data
access code buried deep in the data access layer (DAL)? You don't
actually need a DAL anymore, you just set properties of the data source
and the framework does the dirty work for you.

I agree with your argument when you still have to write code to do some
of the work, but this is supposed to give you code-free data access.
What's more, the underlying code was (hopefully) written and tested by a
team of enterprise programmers. You don't have to develop your own DAL
anymore.

Note that I am not necessarily saying I hold of this point of view, I'm
putting it forward in order to hear your views on it. I'm trying to
understand the deeper issues here, so am playing devil's advocate.
I don't consider the features themeselves to be marketting, but the way they
are talked about is. It's all about saving you 70% time. The truth is that
while it might save you time in some projects (prototyping), it'll cost you
much much more in others
Ah, but why? That's what I want to know. I agree with you completely in
theory, I have seen exactly this in VB6 as I explained earlier. Great
features for simple jobs, but no good for Real World(TM) applications.

What is it about data sources that makes them a problem for real
applications?
- no one ever says that. There needs to be more
guidance about prudent usage, otherwise it IS marketting. Arm developers
with unbiased and real information, build up their knowledge and they'll be
able to understand a problem and find the right solution. Teach a man how
to fish as it were...

Give a man a fish and you'll feed him for a day. Teach him to use the
Internet and you won't hear from him for weeks!!

Thanks for the reply. Any further comments welcome.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Karl Seguin]

Well, I think I've answered a lot of your questions. They make it
impossible to write proper OO code or tiered code. The implications of this
are pretty straighforward. Where do you put your business rules? How do
you ensure they are reusable? How do you promote an API? I'm sure it all
works properly and bug-free, but it's just a piece of code, where's the
check to make sure a valid "name" property is entered? In the web-ui? So
what happens when you expose it as a webservice? You'll replicate the
business rule in that presentation layer. You end up with a dos console,
and now when you need to change 1 simple business rule, you are recompiling
3 applications?

karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:w+**************@nospamthankyou.spam...

Well, I cringe when I see a button's click event open op a connection,
create a command and populate a dataset. The code because totally
un-reusable. It's fine for my dad's website, but not for the enterprise
architecture I'm building, which will eventually need to have a web
service.
The code in the button click should be quite deeper, it should be
encapsulated in a data access layer and exposed via a rich business layer.
By doing so, I've increased my testability (unit tests on business and
data
layers are easier than presentation layers), my reusability and
maintainability (oh geez, who would have though saving a product begins in
the Product class!).

Instead of promoting rich tiering, the XXXDataSource actually thin the
tiers
even more. I thought doing database work in the button's click was bad,
now
people are doing it in HTML.

OK, that all makes sense, but let's assume for a moment that the stuff
actually works properly. If so, then why do you need to have the data
access code buried deep in the data access layer (DAL)? You don't actually
need a DAL anymore, you just set properties of the data source and the
framework does the dirty work for you.

I agree with your argument when you still have to write code to do some of
the work, but this is supposed to give you code-free data access. What's
more, the underlying code was (hopefully) written and tested by a team of
enterprise programmers. You don't have to develop your own DAL anymore.

Note that I am not necessarily saying I hold of this point of view, I'm
putting it forward in order to hear your views on it. I'm trying to
understand the deeper issues here, so am playing devil's advocate.

I don't consider the features themeselves to be marketting, but the way
they
are talked about is. It's all about saving you 70% time. The truth is
that
while it might save you time in some projects (prototyping), it'll cost
you
much much more in others

Ah, but why? That's what I want to know. I agree with you completely in
theory, I have seen exactly this in VB6 as I explained earlier. Great
features for simple jobs, but no good for Real World(TM) applications.

What is it about data sources that makes them a problem for real
applications?

- no one ever says that. There needs to be more
guidance about prudent usage, otherwise it IS marketting. Arm developers
with unbiased and real information, build up their knowledge and they'll
be
able to understand a problem and find the right solution. Teach a man how
to fish as it were...

Give a man a fish and you'll feed him for a day. Teach him to use the
Internet and you won't hear from him for weeks!!

Thanks for the reply. Any further comments welcome.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>Well, I think I've answered a lot of your questions. They make it

impossible to write proper OO code or tiered code. The implications of this
are pretty straighforward. Where do you put your business rules? How do
you ensure they are reusable? How do you promote an API? I'm sure it all
works properly and bug-free, but it's just a piece of code, where's the
check to make sure a valid "name" property is entered? In the web-ui? So
what happens when you expose it as a webservice? You'll replicate the
business rule in that presentation layer. You end up with a dos console,
and now when you need to change 1 simple business rule, you are recompiling
3 applications?

Fair points. Thanks for the clarification.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Mikeon]

> ... XXXDataSource ...

Actually ObjectDataSource does not stand against n-tier.

--
Michal

[john_teague]

The ObjectDataSource works okay with an n-tier struction as Mikeon
stated. In fact, there are templates to use NetTiers code generation
to build asp.net entity admin pages.

http://www.nettiers.com

http://forum.codesmithtools.com/defa...px?f=19&m=8294

[Alan Silver]

Any comments Karl?

The ObjectDataSource works okay with an n-tier struction as Mikeon
stated. In fact, there are templates to use NetTiers code generation
to build asp.net entity admin pages.

http://www.nettiers.com

http://forum.codesmithtools.com/defa...px?f=19&m=8294

--
Alan Silver
(anything added below this line is nothing to do with me)

[Karl Seguin]

No. I haven't played enough with it to say anything about it. At the very
least, it seems like the lesser evil of the bunch. My understanding was
that it still promoted a business layer, and while the consumption of that
business layer might be better in codebehind than html, it's not as big a
concern. Of course,I could be talking out my ass about this...so...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:E9**************@nospamthankyou.spam...

Any comments Karl?

The ObjectDataSource works okay with an n-tier struction as Mikeon
stated. In fact, there are templates to use NetTiers code generation
to build asp.net entity admin pages.

http://www.nettiers.com

http://forum.codesmithtools.com/defa...px?f=19&m=8294

--
Alan Silver
(anything added below this line is nothing to do with me)