While I have my own codegenerator to create my code for calling SQL Server procedures etc, I have made the generated code call into a sqlhelper class, sqlhelper.cs.
It was part of Data Access Application block (a Microsoft best practices block), which in it's first version (1.0 and only containing sqlhelper.cs) was really useful. Later it was generelized into some sort of provider structure and became a part of the Enterprise Application Block. If you want to use it now you will need to make tens of additions to your web.config file - I am not even sure that's enough, you even have a GUI application for creating the config files needed...
In my book that's a big joke. I first of all want the code to be easy to follow, then I generally prefer code over configuration (code can be debugged - configuration errors just spits some error information in your face). And last, and maybe not important. I think the whole idea is wrong, from a design perspective. I prefer to write custom application specific data layer providers and use these to form a provider model. Not to write a generic data layer. In my article on ASPCode.net about dynamically loading dll:s in asp.net I show you my way of doing it.
So in the following articles here on SQL Server I will use sqlhelper.cs - and if you are having trouble finding it here it is:
(edit:2007-06-27 look to the right column in downloads)
