Interesting but really pretty common sense. This is a fairly standard data access component and in fact I had built something like this a while ago - it's usually the first order of business before diving into any data development. This thing still requires a fair amount of set up work like pre-configuring connections and transacations, which should be managed through a class interface IMHO.

There are a number of issues with this though - it's not generic as to which type of client is used. If you go with OleDb or Oracle you'll need to scrap the whole thing and re-write especially since it's a non-extensible class.

Good reading though - there are definitely a few things in there I hadn't thought about before either. Although I found myself smirking at the implications


>Hi All,
>
>For those still confused on how ADO.Net works and how to use it to access and update data, one thing that has helped me is the Data Access Application Block that MS has published. This is two classes that encapsulate the various data access methods into some simple methods. Reading about and looking at this code has taught me alot about ADO.Net and how to use it. Also, you can use the ApplicationBlock right in your aps if you want.
>
>You can find it at
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daab-rm.asp
>
>This block is based on the Data Access Architecture guide at
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp
>
>I know these have helped me alot.
>BOb