Question about Datasets and ASP.NET

[Ryan]

I'm in the process of learning more about building my ASP.NET website to use
my SQL datastore and am a bit confused about how ADO.NET works with ASP.NET.
This Microsoft article implies that using ADO.NET with ASP.NET applications
is the way of the past because newer controls allow you to do all your data
binding declaratively.
http://msdn2.microsoft.com/en-us/library/ms178359(d=ide).aspx

However, I haven't been able to get my application to work just using these
controls. There is a lot of complex dataprocessing that needs to be done
with code. For example, once a user completes filling out a resume form I
need to create a new item in the resume table, using the new resumeid I then
need to add rows to multiple tables (lets just say these resume forms are
pretty complex, the questions are created dynamically by backend users and
each form is related to positions they're applying for, the dynamic question
table, etc). So anyways, to cut a long story short, I'm thinking using
ADO.NET Datasets and Datatables is the way to go. I've done pretty well
using these features with my backend application (a Windows project using
Windows forms - not ASP.NET), but for the ASP.NET website user end I'm
missing the Data Sources window and the easy drag-drop capabilities of
creating and managing Datasets (including the Dataset designer). Is
Microsoft trying to discourage me from using Datasets with ASP.NET? What
should I be using to code the database queries? SQLdatasource is nice but
I'm finding it hard to use programmatically. It works nice to bind to
controls but that seems to be the only way it is usable.

Thanks for any advice.
Ryan

 

[PJ6]

This is probably a good example of where you want to compile your business
layer in a separate dll, and have that support both the thin and thick
clients. Ideally your UI layers shouldn't care at all about the details of
data access - that means they won't see data sets.

Also, you may want to think about moving away from data binding - raw SQL,
even if it's automatically generated for you, does not belong in compiled
code. Any data access details that you do have in code, such as column name
mapping to particualr object fields, should be kept non-declarative (i.e.
attributes).

Paul

 

[Ryan]

So I should do all my processing using SQL functions, etc stored on the SQL
server? Can you elaborate on what you mean by attributes (private member
variables of the form?)? Move away from data binding? Why did Microsoft
implement all these new databinding features if I'm not suppose to use them?


Thanks,
Ryan

 

[PJ6]

- So I should do all my processing using SQL functions, etc stored on the
SQL server?

"All processing"? I don't know what you mean by that. But if you mean all
data set manipulation and retrieval, such as selecting from one or more
tables and picking out the rows and columns you want for a particular view
of data, all this information belongs in stored procedures.

- Can you elaborate on what you mean by attributes (private member variables
of the form?)?

A good business layer design pattern is to use attributes to store data
mapping information. So if I want to generate a collection of a particular
object of type "Car" from a data table...

Public Class Car

<MapToColumn("Color")> _
Protected _Color as String

Public Readonly Property Color as String
Get
Return _Color
End Get
End Property

End Class

it's easy to generalize populating the fields from a particular result set
by

1. Creating a new object (in this case, Car) for each row
2. Cycling through each data column in the result set, and matching them up
with and setting the contents of each attributed field

Doing it this way can completely eliminate the need to have code that
specifically mentions each field to populate it. You also (should you ever
have the need) now have the ability to reliably collect data mapping
information in your entire application when it comes time to change the
database.

- Move away from data binding? Why did Microsoft implement all these new
databinding features if I'm not suppose to use them?

Some features or products Microsoft gives developers to use (such as Access)
may be designed for the lowest common denominator of programmer, someone who
is just getting into development and needs an "easy" way into it. Easy is
fine, but it has been my experience that these entry points do not foster
good practice or proper architecture - or proper learning, for that matter.
As an instructor, I've often had to back people up that thought they knew
data access and retrain them, because data binding is all they knew.

Paul

 

[Ryan]

Paul,

Thanks for the very informative post. I'm beginning to see the light I
think

"All processing"? I don't know what you mean by that. But if you mean all
data set manipulation and retrieval, such as selecting from one or more
tables and picking out the rows and columns you want for a particular view
of data, all this information belongs in stored procedures.

Yes by "all processing" I was referring to all my data set manipulation and
retrieval. I'd be glad to move all this to stored procedures on the SQL
server and am definitely more comfortable with that than hardcoding
everything in VB. Thanks for the recommendation.

A good business layer design pattern is to use attributes to store data
mapping information. So if I want to generate a collection of a particular
object of type "Car" from a data table...

I'm new to this using attributes for data mapping information. But I'm not
new to OOP with classes so I think I can catch on pretty quick. If you have
any "recommended reading" I'd be glad to hear about any of it, otherwise
I'll be browsing the help and MSDN online files.

Thanks again,
Ryan

 

[Ryan]

Paul where do you teach? I think I need to come take your class. I'm
just not finding any information on using attributes to map data.

Ryan

 

[PJ6]

I'm new to this using attributes for data mapping information. But I'm

not new to OOP with classes so I think I can catch on pretty quick. If
you have any "recommended reading" I'd be glad to hear about any of it,
otherwise I'll be browsing the help and MSDN online files.

I recommend "Data Access Patterns" by Clifton Nock.

Paul

 

[PJ6]

I teach in Boston.

Among a surprising number of other things, data mapping with attribution is
something I've used for years to great benefit, but I never wrote up
anything on it because I sort of thought it was smack-yourself-in-the-head
obvious to anyone who's had to manage database changes for a large enough
application... but here we are in 2006 and MS is still pushing a bad design
pattern. I've been asked before to write my own patterns and practices
paper, and I'm actually in the middle of doing that now. I humbly accept
that little if anything I talk about I will have thought of first, but when
my paper is complete and it's had some peer review I'll post a link to it
here in a few months.

Paul