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/lib...59(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 programmaticall y. 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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

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/lib...59(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
programmaticall y. It works nice to bind to controls but that seems to be
the only way it is usable.

Thanks for any advice.
Ryan

[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" <no***@nowhere. net> wrote in message
news:eB******** ******@TK2MSFTN GP03.phx.gbl...

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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

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/lib...59(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 programmaticall y. It works nice to bind to
controls but that seems to be the only way it is usable.

Thanks for any advice.
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("C olor")> _
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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** **********@TK2M SFTNGP02.phx.gb l...

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" <no***@nowhere. net> wrote in message
news:eB******** ******@TK2MSFTN GP03.phx.gbl...

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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

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/lib...59(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 programmaticall y. It works nice to bind to
controls but that seems to be the only way it is usable.

Thanks for any advice.
Ryan

[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 "recommende d 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
"PJ6" <no***@nowhere. net> wrote in message
news:et******** ********@TK2MSF TNGP03.phx.gbl. ..- 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("C olor")> _
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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** **********@TK2M SFTNGP02.phx.gb l...

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" <no***@nowhere. net> wrote in message
news:eB******** ******@TK2MSFTN GP03.phx.gbl...

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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..
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/lib...59(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 programmaticall y. It works nice to bind to
controls but that seems to be the only way it is usable.

Thanks for any advice.
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

"Ryan" <Ty****@newsgro ups.nospam> wrote in message
news:OI******** ******@TK2MSFTN GP04.phx.gbl...

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 "recommende d 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
"PJ6" <no***@nowhere. net> wrote in message
news:et******** ********@TK2MSF TNGP03.phx.gbl. ..

- 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("C olor")> _
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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** **********@TK2M SFTNGP02.phx.gb l...

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" <no***@nowhere. net> wrote in message
news:eB******** ******@TK2MSFTN GP03.phx.gbl...
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" <Ty****@newsgro ups.nospam> wrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..
> 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/lib...59(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 programmaticall y. It works nice
> to bind to controls but that seems to be the only way it is usable.
>
> Thanks for any advice.
> 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 "recommende d 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

"Ryan" <Ty****@newsgro ups.nospam> wrote in message
news:ev******** ******@TK2MSFTN GP02.phx.gbl...

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