First off, good job. I am starting to see this a lot, my company does something similar where they just make strongly-typed Stored Procedure classes. I've actually had a framework for DataAccess for many years that requires no custom code or code generators and supports ORM. This has helped me over the years get things up and running with data access with only 1 AppSetting and very easy calling code.

For example:

Dictionary<string, object> parameters = new Dictionary<string, object>();

parameters.Add("@OrderID", orderId);

DataTable dtData = DataService.Fill ("dbo.usp_MyStoredProc", CommandType.StoredProcedure, parameters);

If I just want to execute the Proc without any returns, it's just as easy:

int hResult = DataService.ExecuteNonQuery("dbo.usp_MyStoredProc", CommandType.StoredProcedure, parameters);

System.Diagnostics.Debug.WriteLine("Rows Affected: " + hResult.ToString());

I've seen these strongly-typed stored-proc classes being generated now in some peoples frameworks and to me, it's still too complicated. I have no extra code to maintain, the DAL does it all. It takes care of building the Procs on the fly (caching them for a relative period of time that can be configured) so that subsequent calls to the same proc are as fast as possible. I've thought about posting the code for some time, I just wanted to get support in there for the IQueryable interface for LINQ so that it could run LINQ queries as well.

Oh, by the way, it also supports Data-Paging out of the box and optimizes any ad-hoc sql you write. It does not let any "Select *" statements come across the wire and also helps you parametrize all ad-hoc sql statements if you choose to use them (and you will, once you start data paging).

That's my 2cents...