Hello Fredrik and thanks for your participation on this thread!

Keep it coming! Could you please send your test-code to my private 

e-mail (lundholm@s...)?! I'd like to see your approach.



> I don't believe this, ASP v 3,0 with ADO 2.6 and SQLOLEDB provider is 

much

> faster than ASP.NET with SQLCommand.



Perhaps this is because the SQL namespace has been compiled with the 

debug option on?! As far as I'm concerned, this has a dramatic 

performance setback. Most .NET developers will be interfacing with 

databases (atleas the ASP.NET ones) and if MicroSoft can't come up with 

a faster engine than that, they're in deep trouble.



However .. they show the SQLDataReader as an extremely hardcore cursor 

to hose data onto a page. My test indicates atleast 4 x speed compared 

to that of ADO. The issue here is the SQLConnection .. shame on them I 

say! =3Do)



> NOTE: This is only a test, I will never use this in a real 

application, but

> it's fun to compare how long it takes for a connection to be open with 

ASP

> vs ASP.NET.



I don't think it's fun at all. I think it's really scary that compiled 

code can be outperformed by a simple script. I had expected the SQL.NET 

to outperform ADO by several factors.



With Regards

Anders Lundholm - lundholm@s...

--

Hello!



First of all, having a data-depency (imho) from the businesslayer to the 

datalayer isn't a big problem. If you consider the fact that you 'ask' 

the datalayer to do something for you (e. g. retrieve some records and 

return a SQLDataReader or just a string), then the datalayer would need 

to know HOW to connect to the data!



How could the datalayer connect to the data if it doesn't get either a 

DSN or valid connection as input? Would one want to hardcore the DSN? 

Not likely! Would one want to make use of a global variable (e. g. 

located in an Application variable)?! Not likely, it'd limit the use of 

the datalayer to ASP.NET pages only.



Thus, the only way (I could think of) to enable the datalayer to connect 

to the datasource would be to use a connection or DSN-string as argument 

to the function/constructor. I bet this is because I'm not used to true 

OOP, but the widely spread include-directive from regular ASP.



>Any downside to creating and opening the connection objects in my 

business layer >is far less than the downside and the performance loss 

that I will incur by creating >and opening multiple Connection objects.



I totally agree Scott! More later..

I'm really open to new inputs!



Please advice books on OO and I'll buy them instantly!



With Regards

Anders Lundholm - lundholm@s...

--