Best practice and considerations in choosing source for an <ObjectDataSource>

[ajmastrean]

Folks,

What are the best practices, pros/cons, performance, scalability
considerations in choosing the source/type for an object's
ObjectDataSource (consider a GridView that needs to display a SELECT
statement from a table external to the website).

I have identified several alternatives...

1. Use a custom or pre-built data access class to provide SELECT
functions

2. Create DataSets for each SELECT statement, storing them in App_Data

3. Configure a connection to the database through the config wizard

 

[Mark Rae]

What are the best practices, pros/cons, performance, scalability
considerations in choosing the source/type for an object's
ObjectDataSource (consider a GridView that needs to display a SELECT
statement from a table external to the website).

I have identified several alternatives...

1. Use a custom or pre-built data access class to provide SELECT
functions

2. Create DataSets for each SELECT statement, storing them in App_Data

3. Configure a connection to the database through the config wizard

IMO, none of them.

4. Use a DAL instead, create a DataSet or SqlDataReader object and do your
databinding in code-behind:
http://www.microsoft.com/downloads/...0a-9877-4a7b-88ec-0426b48df275&displaylang=en

 

[ajmastrean]

Mark,

I think we have a bit of communication confusion...

Item 1 was actually a reference to the data access application block
(albeit, version 3.0). While this alternative is doable (in fact, my
prototype is using it), are there issues to be concerned with? For
instance, what if I want to use strongly typed data sets? I have to
create objects using the app block _and_ data sets and then fill the
data set from the LoadDataSet method.

Is using a strongly typed data sets and table adapters to do the
querying better? Is running straight SQL against a connection string
(using the Object Data Source Wizard and choosing Database) faster?

These are the things I am interested in.

 

[Mark Rae]

I think we have a bit of communication confusion...

Item 1 was actually a reference to the data access application block
(albeit, version 3.0).

My apologies - I didn't read your OP closely enough...

While this alternative is doable (in fact, my prototype is using it), are
there issues to be concerned with?

None that I can think of - I never use anything else...

For instance, what if I want to use strongly typed data sets?

That's what the LoadDataSet method is for...
http://www.google.co.uk/search?hl=en&rlz=1T4GGIH_en-GBGB220GB220&q=Microsoft+DAAB+strongly&meta=

Is using a strongly typed data sets and table adapters to do the
querying better?

Better in what sense...?

Is running straight SQL against a connection string (using the Object
Data Source Wizard and choosing Database) faster?

No.

 

[ajmastrean]

I have been investigating enterprise architecture for an application
like this...

Presentation <-> Business logic <-> Data access <-> Database

My issue is mainly between the Business logic and Data access layers.

1. I can have Visual Studio create strongly typed DataSets
with the connection strings, select/update queries built in,
and enforce logic with properties... all without writing any
code!

2. Or, using a Data access class, I could stop the DataSet when
moving up or down the layers and enforce the business rules there
(check values, allow or deny updates, enforce min/max values).
<http://weblogs.asp.net/rosherove/archive/2003/07/28/10607.aspx>

3. Or, I can use the wizard-built DataSets, intercept the
TableAdapter
class in another class, intercept the DataSets, and enforce
business
rules there.
<http://www.asp.net/learn/dataaccess/tutorial02cs.aspx?tabid=63>

And all 3 of these methods can be bound to controls and manage the db
connections properly.