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/library/system.web.ui.webcontrols.sqldatasource.aspx
http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.sqldatasource_members.aspx
http://dotnetjunkies.com/QuickStartv20/aspnet/doc/ctrlref/data/sqldatasource.aspx
http://gridviewguy.com/ArticleDetails.aspx?articleID=147
http://geekswithblogs.net/lorint/archive/2006/02/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.
