Poor DAB performance

  • Thread starter Thread starter DaveK
  • Start date Start date
D

DaveK

I recently came across the Microsoft Data Access Application Block so I
decided to try it out in a Windows forms application. Without using the
DAAB, the following code, which creates a data reader which is then
used to populate a combo box, takes 3 seconds to run:

SqlConnection cn = new SqlConnection("server=.......")
commandString = "select ......"
SqlCommand cmd = new SqlCommand(commandString, cn);
SqlDataReader dr = cmd.ExecuteReader();

The command string is a simple select statement on one table which
returns the primary key for about 10 records.

After installing the DAAB I modified the code as follows:

Database db = DatabaseFactory.CreateDatabase();
commandString = "select ......"
DBCommandWrapper dbCommandWrapper(commandString);
IDataReader DataReader = db.ExecuteReader(dbCommandWrapper);

This code takes 6 seconds to run, twice as long. I can see the
advantages of using the DAAB, but this performance overhead is too
great. Is this to be expected when using the DAAB or am I missing
something?
 
IMHO, the DAB is unnecessary. It raises a number of issues that will never
be resolved. The DAB requires that developers learn yet another data access
development paradigm to do something that's not that hard to do in "native"
ADO.NET. It often uses generic OSFA interfaces that don't adapt to specific
applications very well. As far as I can see they don't solve any ADO.NET
problems that could not be solved just as easily with your own code.



--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
I'm glad I'm not the only one. One of my favorites is when people try to
Remote DataReaders because you can "remote everything else"

The block has value and is a good starting point, but that's it. There's a
whole lot of clients these days that deem it the be all and end all and I've
had more than a few frustrating conversations trying to convince them
otherwise. "Well, I know your version has Async methods but I think
Microsoft would have put them there if they were intented to be there in the
frist place" and other stuff like that. It's annoying to say the least.
 
William Ryan eMVP said:
to convince them otherwise. "Well, I know your version has Async
methods but I think Microsoft would have put them there if they were
intented to be there in the frist place" and other stuff like that.
It's annoying to say the least.
Click to expand...

Spot on. I spend so much time trying to communicate this to users. They read something on the MS site
and assume its a solution to everything, and that this also means there are NO other solutions.
 
Back
Top