Question

We’re using Stored Procedures for every query to the DB. This seems incredibly un-DRY:

1. Design the table
2. Design CRUD operation SPs for that table
3. Design code (preferably a class) to fill parameters and execute CRUD SPs

If we add a single column, or change a datatype, we have to edit the table, a handful of SPs, and a handful of functions in a class within .NET.

What are some tips for reducing this duplication?

UPDATE:

In combination with Vinko’s idea, I found this. Here’s a bit of code (in C#) that I came up with for those that need it:

SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings['MySQLConnString'].ConnectionString); SqlCommand comm = new SqlCommand('NameOfStoredProcedure', conn); comm.CommandType = CommandType.StoredProcedure;  conn.Open(); SqlCommandBuilder.DeriveParameters(comm); conn.Close();  foreach (SqlParameter param in comm.Parameters) { /* do stuff */ } 

Answer 1

One tip to avoid modification of at least the SPs is writing them to use ‘introspection’, that is, deducing the column names and datatypes from the internal tables or the information_schema views.

It’s more complex code to write, but it’ll avoid having to modify it each time the table changes, and it can be reused in the rest of the SPs.

Create a single SP that will describe the tables for you, for instance using a temp table (colname varchar, type varchar) that you’ll call from the rest of SPs.

By the way, this can get very complex and even unfeasible if your queries are complex, but on the other hand, if they are not, it can save you a lot of trouble.