Application blocks.. benefits?

I assume most people are familiar with the Microsoft Application blocks for database, exception handling and authorization... my question is:

How did you incorporate these blocks into your companys applications? Was it a success or faliure in doing so? How many hours did you allocate in learning how to use them?

Is it worth the time it takes to use them, rather than write your own exception, dbgateway and authorization class?? The application blocks are very extensive... and tha tisn't always what you need :)


kind regards
Henrik

take a look here.

http://www.vbforums.com/showthread.p...hreadid=241866

I love the data access one. All our development from here on out will use the data access one. It is actually part of our code review process now. I can't think of much of a reason to not use it. If you have your own code already written, I would bet it doesn't even compare to the application block (at least 99% of the 'home' grown ones don't).

I takes only about 3 hours of playing with it to fully understand it. I don't see time as an issue.


Now, when we start talking about other blocks, well, that is up to you. I haven't used them all either, so I can't speak very well on them. I do know that the exception management block is pretty powerful and requires a little time investment to fully use it.

Bieng one of the few the proud the ignorant. Somebody clue me in.

I already made my own though and it is performing well it returns a DataObject that implicit moves Data between data objects (Readers, Arrays, DataSets, and I am considering doing some collections). It isn't slow because you exectue a storded procedure or SQL statement and the DataObject is setup as a type you passed in. Seems to be DataSet allot... Anyway. If you get data as a Reader(OLeDB or SQL) and you keep converting it between dataset and reader it doesn't hit the database again but it does have to manipulate data into what ever your casting it as.

If that makes any since.... It's Like A Variant that can only be DataObjects but there is proccessing required for it to move from the intial object it repesents to the one you want it to actlike.... Anyway I like it just don't use one DataObject as an Array, a Reader and a DataSet all at the sametime because I know that would be slow.

That is what a lot of people have done...rolled their own. MS just took the best practices out there, and put them together in the Data Access Application Block.

If your way works, then keep using it.

I personally like a standard approach such as this. We can have every developer using this, and no having to go in and work out little bugs. For me, this block has been extremely error proof. Sure, there probably is one or two in there, but I think it is rock solid. It isn't hard to use either:

dim ds as DataSet = SqlHelper.ExecuteDataset(strConn, StoredProcedure, "storedProcName")

Or if I want a DataReader:
dim ds as SqlDataReader= SqlHelper.ExecuteReader(strConn, StoredProcedure, "storedProcName")

Not bad, and it is overloaded with almost anything you want to add. Supports transactions, parameter arrays, has the parameter cache object, etc....

Thank you for the replies... my main concern is that the people in my company that wear suits every day and earn ten times my money has decided to use oracle db even though we use MS for everything else, development, messaging, businses logic etc...

And what I can figure out from reading through the data app block is that it can only identify stored procedure parameters on sql server? I saw that as a main advantage. Well it's no big deal to pass the parameters as some kind of name-value collection... but it was a nice feature. I will however start to play with the data app block.. and give it some workouts ;)


thank you for the replies...

yours
Henrik

Yes, the data application block is only for SQL Server. That is the downside.

But, since all the source code is included, you could probably roll your own fairly quickly for Oracle.