By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,984 Members | 1,421 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,984 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Jun 6 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"ajmastrean" <aj********@gmail.comwrote in message
news:11*********************@g4g2000hsf.googlegrou ps.com...
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/d...displaylang=en
--
http://www.markrae.net

Jun 6 '07 #2

P: n/a
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.

Jun 7 '07 #3

P: n/a
"ajmastrean" <aj********@gmail.comwrote in message
news:11*********************@h2g2000hsg.googlegrou ps.com...
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...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.
--
http://www.markrae.net

Jun 8 '07 #4

P: n/a
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.

Jun 13 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.