Question

I’m sure this has been asked; but I can’t find the exact context. Would this be a novice or ill-advised approach? Or is this an acceptable approach.

I have a project in which I’m working on. I have these four tables:

• Customer
• Address
• Site
• Login

So the database is basic, nothing too crazy.

But I’ve created a Restful Service to link my Client to my Server. Which to perform my Crud Operation will require a simple Insert Command.

Like:

 string sqlInsertStr = "INSERT INTO Customer (First, Last, Phone, Email) 
         VALUES (@first, @last, @phone, @email)";

So that’d handle one of my four tables; my thought was one of these two approaches:

1. Use a Generic to store each individual Query; then loop to iterate each query.
2. Use a Generic that contains a series of Stored Procedures to iterate through.

My goal is to avoid several strings to iterate through and write to the database.

My reasoning was, when a client modifies an individual field or an entire profile; it would handle all the tables congruently. In SQL I know it has limitations when trying to insert data across multiple tables.

Is that a bad approach; this particular is fairly small and simple. So I’m not looking to go to crazy; but it is for school. So I’m trying to understand if I’m even coming up with a valid solution, and if I am is it considered a right solution?

Any input on the matter and explanation would be terrific.

---

Update:

I apologize for the confusion; yes I have one Object Model- which contains all the information for each column of each table. My question is this:

SQL does not like Inserting across multiple tables. So this works just fine for one table:

using (connection)
{
      string sqlInsertStr = "INSERT INTO Customer (First, Last, Phone, Email) 
             VALUES (@first, @last, @phone, @email)";
      connection = new SqlConnection(connectionStr);
      command = new SqlCommand();
      command.Connection = connection;
      command.Connection.Open();
      command.CommandText = sqlInsertStr;

      SqlParameter firstParam = new SqlParameter(@"first", cust.First);
      SqlParameter lastParam = new SqlParameter(@"last", cust.Last);
      SqlParameter phoneParam = new SqlParameter(@"phone", cust.Phone);
      SqlParameter emailParam = new SqlParameter(@"email", cust.Email);

      command.Parameters.AddRange(new SqlParameter[] 
              { firstParam, lastParam, phoneParam, emailParam});
      command.ExecuteNonQuery();
      command.Connection.Close();
}

That will easily write to the one table; but what about all the other data that needs to be inserted to those other tables? Would I need to create a sqlInsertStr for each table? Or couldn’t I simply do something like this:

using(connection)
{
     list<string> sqlInsertStr = new list<string>();
     sqlInsertStr.Add("INSERT INTO Customer (First, Last, Phone, Email) 
              VALUES (@first, @last, @phone, @email)"l
     sqlInsertStr.Add("INSERT INTO Address (Street, City, State, Zip, Country)
               VALUES (@Street, @City, @State, @Zip, @Country)";

     connection = new SqlConnection(connectionStr);
     command = new SqlCommand();
     command.Connection = connection;
     command.CommandText = sqlInsertStr;

     // Repeat with Parameters and etc.
}

So wouldn’t essentially using a Generic or StringBuilder allow me to just include one string to handle all those Inserts with the proper data? Or am I completely over-thinking / confusing myself. I’m still learning, so an explanation would be great.

Answer 1

Based on the numerous questions here on making it work, I would recommend not trying to be clever by genericizing too much. My recommended approach for any problem is:

1. Make it work – by any means necessary (even {gasp} copy-and-paste)
2. Make it better – refactoring, genericizing, etc.
3. Make it faster – by profiling and looking at the SLOWEST pieces first

Too many people try to do 2) and 3) before it even works and end up spending more time hacking or micro-optimizing just to get it to work. If you get it to work first, you can always throw away your optimizations and start over, and you still have a working product!

All that to say, don’t worry about generics yet – create four repositories (one for each table), then analyze and see if Generics can make is cleaner.

Comment on your update

am I completely over-thinking / confusing myself

It sounds like it. Don’t try to make one class handle CRUD operations for all types just to avoid using the same connection/command code in multiple places. Each repository (and I’m using that term loosely, meaning some class that handles the CRUD operations) should have its own connection/command code. If later you decide that you can create a base class that deals with the grunge work, that’s fine – or you can use a ORM layer like Entity Framework or NHibernate to handle that for you. Or you can have a mixture. Whatever works best AFTER you get it to work. 🙂