Let’s start with a quick definition of data binding. Data
binding is probably best described as the process of
creating an association between a GUI object and one
or more data elements. In this simple definition, the
GUI object might be a data grid in a Windows form,
or a list that’s part of an ASP.NET Web page, or a text
box, or anything else that might display application
data. The data element could be a table from a database,
a set of XML data, or a custom object created
to hold an array of data.
Data binding is a broad topic, and yet there are
several commonalities between its different forms.
This article focuses on .NET 2.0—not 3.0 or 3.5—so
you won’t find any Windows Presentation Format
(WPF)– or Language-Integrated Query (LINQ)–
specific information—and further, I’m going to focus
on simple Windows Forms–based and ASP.NETbased
examples. Several other ancillary topics, such as
data-binding to XML, don’t quite fit within the confines
of a single introductory article. If you have specific
areas you’d like to see covered, feel free to contact
us or visit our forums at www.sqlmag.com.
In addition to introducing the concept of data
binding through simple examples, this article runs
through some data-binding best practices. The
first such best practice is the use of stored procedures.
A key feature that data binding supports
is the use of stored procedures to Get,
Update, Insert, and Delete data. Although it’s
possible to bind directly to data tables defined in your
database, it isn’t a best practice. With that in mind,
how about a quick review of the advantages of stored
procedures versus other data-access methods?
Data-Access Security
There’s been a debate about the best way to access data.
Generally, you’ll find that most published examples
use Dynamic SQL, in which the demo author takes a
raw Select statement and embeds it as a string within
the application code. However, this type of data access
has been repeatedly shown to be completely open
to hacking through SQL injection attacks and is usually
considered amongst the worst practices. For more
information about this vulnerability, see “Preventing
SQL Injection Attack” (InstantDoc ID 43012).
A somewhat more secure method of working with
your database is to use parameterized queries, which
have the advantage of preventing SQL injection attacks
but fail in defending against a different attack
vector.
Parameterized queries limit the available security
options that you can apply to objects in your database.
If you’re using parameterized queries, the user
needs permission to access the table that the query
references. However, with stored procedures, the most
secure method of accessing data, SQL Server lets you
grant users permission to access only the stored procedure—
not the underlying table.
Setting Up Stored Procedures
For this article, I’ve created four new stored procedures
against the sample Northwind database, which
is available for both SQL Server 2005 and 2000. Web
Listing 1 provides the T-SQL code for building the
stored procedures in your own copy of Northwind.
The four new stored procedures carry out the Select,
Insert, Update, and Delete actions. (Note that I don’t
try to retrieve every column from the table—simply
some of the date columns and key relationship columns.)
The Select statement retrieves all the fields
of interest, as opposed to all columns. The Insert
statement lets you create a new order for a customer
with any of the three dates. The Update statement,
however, allows for editing of only the requested and
shipped dates.
(see WebListing 1)
These statements are simple—not what I’d consider production quality—but they do serve to illustrate
custom stored procedures that require specific parameters.
As such, they’ll provide a solid basis for designing
a standard typed data provider for both ASP.
NET and Windows Forms to illustrate data binding
and the differences in each environment. For example,
the Delete stored procedure actually deletes a row. In
reality, I’d mark a row as inactive or deleted and track
who made that update. (see WebListing 2)
Windows Forms and ASP.NET
For the purpose of this article, I’ll go through a Windows
Forms example that uses a label and text box
in the upper left corner of the window, a refresh button
on the upper right corner, and a DataGridView
control to fill in the display. Similarly, the ASP.NET
control will have a label and text box in the upper left
corner, a refresh button on the upper right corner, and
a GridView control to fill in the display. After creating
the data objects for both solutions, I’ll look at incorporating
the data objects and dive into some of the
more project-specific requirements.
You might expect that Windows Forms and ASP
.NET would have similar functionality, but there are
quite a few differences. Yes, each solution is wizarddriven
and lets you create a data adapter based on your
stored procedures, but the end results are distinctly different.
The good news is that the processes are similar
enough to be compared and contrasted in context.
Prev. page
[1]
2
3
next page 
