You're correct in your understanding of what the SqlDataSource component
does. However, it isn't really important whether you're using Stored
Procedures or Queries to fetch data. I'll get into that in a moment, after
reviewing the underlying principles.
Starting from the beginning: Writing software is the process of writing
machine instructions in binary code. As both hardware and software
technology has grown, the ability to write pure machine code has become
impractical. As an answer, beginning with Assembler code, common patterns of
machine code were combined into higher-level human-readable programming
languages. These languages enabled developers to write more code in less
time. Again, as technology continued to grow, various common patterns of
these higher-level language instructions were combined into even
higher-level programming languages and technologies, such as Object-Oriented
Programming, which enables one to encapsulate a vast variety of data and
process into a single "class" entity.
Visual Tool Sets like Microsoft Visual Studio enhance the experience even
more, by providing tools that write programming code for you, enabling you
to use visual tools and drag and drop technology to visually design
components, for which Visual Studio writes the code. Underneath it all,
however, every developer is still, more and more indirectly, writing code.
The SqlDataSource component combines several classes into a component
interface that can be designed visually, and easily performs the most common
types of tasks with ASP.Net web data display pages. It is, however,
configurable in a number of ways. For example, you don't need to just drag
and drop a component onto a page. You can exert more control by writing your
own code. And it exposes properties that can be changed "on the fly," such
as the Connection String, SelectCommand, and SelectParameters. So, while it
might certainly be quicker in the short run to drag several SqlDataSources
onto a page, one for each type of data you might need, it is not always
necessary. One SqlDataSource can function at different times as a
SqlDataSource for a number of different data sources and operations.
Again, the SqlDataSource encapsulates the most common types of data
display/interaction functionalities. It is most useful when building a
visual web interface for working with strictly tabular data, and that is,
indeed, the most common functionality. However, there are many other
less-common types of operations that can be performed with an underlying
data store, and for many of these you will not need the overhead involved in
creating such a large component. In such cases, you might only need, for
example, a Connection, Command, and a DataReader.
That's what I was getting at in my first message. Here are a few links that
should help:
http://msdn2.microsoft.com/en-us/lib...atasource.aspx http://msdn2.microsoft.com/en-us/lib...e_members.aspx http://dotnetjunkies.com/QuickStartv...atasource.aspx http://gridviewguy.com/ArticleDetail...?articleID=147 http://geekswithblogs.net/lorint/arc.../20/70195.aspx
--
HTH,
Kevin Spencer
Microsoft MVP
Ministry of Software Development
http://unclechutney.blogspot.com
I just flew in from Chicago with
a man with a wooden leg named Smith
who shot an elephant in my pajamas.
So I bit him.
"RAR in WA" <RA*****@discussions.microsoft.comwrote in message
news:1C**********************************@microsof t.com...
Thanks for the reply.
The components seem to wrap up the functionality of dataadapter/command
and
connection. If I'm using stored procedures for retreiving data, isn't it
more
direct to create the connection and command when I need them, and re-use
the
connection if I need another request, instead of using a different
SQLDataSource for each request? Or am I missing something about the SQL
data
source?
"Kevin Spencer" wrote:
>Both methods have their place. I would advise you to understand what the
components do, rather than to depend on them, and then use them when
appropriate. If you understand what they do, you should be able to
discern
when they are appropriate.
--
HTH,
Kevin Spencer
Microsoft MVP
Ministry of Software Development
http://unclechutney.blogspot.com
I just flew in from Chicago with
a man with a wooden leg named Smith
who shot an elephant in my pajamas.
So I bit him.
"RAR in WA" <RAR in WA@discussions.microsoft.comwrote in message
news:55**********************************@microso ft.com...
I'm moving to .Net framework 2.0 from Visual Studio 2002/3 with more
time
on
desktop apps than ASP.Net, although I have done a small amount in
ASP.Net.
Is
best practice for ASP.Net now to use the components for data access, or
to
build your own connection and command objects in code? I find working
with
the designer to be awkward and hard to follow the details, and would
like
to
know if I really should get used to doing things with components and
not
in
code. Thanks in advance.
