Click to See Complete Forum and Search --> : Data Access Application Block


RickCrone
May 31st, 2007, 01:58 PM
I have been looking at the Data Access Application Block in the Enerprise Library 3.1 - May 2007. I have created the Quick Start application and examained it. I have read through the documentation.

I have my own libray functions to access SQL databases and I don't expect to need to change to another database.

I have been concidering re-writing my classes to use the Data Access Application Block.

My question is have YOU used the Data Access Application Block?

What is the main reason you decided to use the Data Access Application Block?

How is the performance?

Is there anything to look out for if you use the Data Access Application Block?

I think I understand form the documentation what the GetStoredProcCommand does... but I'm unclear as to how that effects (helps with) the AddInParameter() and AddOutParamter() functions. Can you explain that part?

TheCPUWizard
May 31st, 2007, 02:30 PM
I have been looking at the Data Access Application Block in the Enerprise Library 3.1 - May 2007. I have created the Quick Start application and examained it. I have read through the documentation.

I have my own libray functions to access SQL databases and I don't expect to need to change to another database.

I have been concidering re-writing my classes to use the Data Access Application Block.

My question is have YOU used the Data Access Application Block?

Yes, all of my designs since about 2004 have been based on the P&P material (with extensions, but never modifications).


What is the main reason you decided to use the Data Access Application Block?

Where applicable using proven material saves money (or for those who are just doing it for fun...time). I started using the DAAB, before EntLib was a coherent entity, in the fairly early days of .Net 1.1. Now most of my development is in .Net 3.0. I have not had so spend any (significant) effort to have my whole "infrastructure" upgraded.

Additionally, if I have to outsource, or hire. I can look for people who have direct experience. Very rare to find someone who has experience with something custome developed in house. ;)


How is the performance?

I have never had a performance issue (determined by measurements at the application performance level), that I could trace to any of the P&P blocks.


Is there anything to look out for if you use the Data Access Application Block?

Nothing really specific. I strongly recomment spending some time with the tutorials, and quickstarts. If you "get the urge" to start modifying (rather than extending), take a deep breath, step back, and review the situation.


I think I understand form the documentation what the GetStoredProcCommand does... but I'm unclear as to how that effects (helps with) the AddInParameter() and AddOutParamter() functions. Can you explain that part?
Not exactly sure what you are looking for here.....

RickCrone
May 31st, 2007, 05:38 PM
Thank you.

Your response is just what I was looking for!

TheCPUWizard
May 31st, 2007, 05:50 PM
Thank you.

Your response is just what I was looking for!
=====
I'm using VS 2005 except for C++ I'm using the old 6.0.

You are welcome (dont forget to rate :wave:

Just curious why you are using an ond non-standards compliant compiler, when you have the newer compliant compiler available with VS-2005 for your C++ :confused: :confused: :confused: :confused:

RickCrone
June 5th, 2007, 01:12 PM
I did rate you!

I use VC++ 6.0 because I have a lot of MFC. I don't care to try to move my C++ to the new MFC.

I plan to just rewrite for C# when I need to update any old apps.

TheCPUWizard
June 5th, 2007, 02:04 PM
I did rate you!

I use VC++ 6.0 because I have a lot of MFC. I don't care to try to move my C++ to the new MFC.

I plan to just rewrite for C# when I need to update any old apps.

Thanks for the rating (one can not read back ratings) :wave:

Although I have not done much of it myself, the people I know that have ported MFC based applications did not have many issues related directly to MFC. Most of the issues were related to the (much better) standards compliance. So if you have been careful to write compliant code (even though VC 6.0 did not require it), it [i]might[/b] be worthwhile.