> 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+DAA
B+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.

Signature
http://www.markrae.net
ajmastrean - 13 Jun 2007 15:48 GMT
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.