Do you use the new datasource controls?

A

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.
 
K

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
 
E

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.
 
A

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.
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.
 
A

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.
 
K

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
 
A

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.
 
K

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
 
A

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.
 
K

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top