Question

Slightly possible duplicate :

Instance method vs. static method with ref parameter

If I have a class Employee, and there’s a method AddEmployee which adds the employee to database. There are tho methods that I can adopt, one is like this,

protected void AddEmployee(SQLConnection con)
{
    // this is an instance method, 
    // connection is passed in parameter
    // add this class to database, using the connection
}

and I would call it like this

   var emp = new Employee();
   // set its properties
   emp.AddEmployee(theSQLConnectionObject);

The other approach is that, I create a static method, and then pass an instance of Employee class, and a SQLConnecion, and then add that instance of employee class to the database, like this

static protected void AddEmployee(Employee emp, SQLConnection Con)
{
    // this is static method
    // connection again in parameter
    // add emp class to database, using the connection
}

this can be added as,

var emp = new Employee();
// set its properties
Employee.AddEmployee(emp, theSQLConnectionObject);

I wanna know which one is good approach, which one do you prefer, and why? Also, I wanna know C# specific, the related question isn’t any lang specific.

Now, in starting I said slightly possible duplicate because of this part.
I was reading CLR Via C#, and in Chapter 8 Section Type Constructors, it goes like

When compiling a method, JIT compiler determines weather it must emit
a call to execute a type constructor into the method. If the JIT
compiler decides to emit the call, it must decide where it should emit
the call. There are two possibilites

• Precise semantics, emit the call immediately before code that would create first instance or immediately before code that access a
  noninherited filed of member of the class.

• Before-field-init semantics, emit the code sometime before the code fist access a static field or a static or instance method, or invokes
  an instance constructor.

Some more description, and then an example of performance comparison was given, and there was a quite a lot of difference in performance, I am not including that for sake of brevity, but if anyone want that, comment and I’ll update the question.
After the example, he continues

When C# compiler sees a class with
static fields that use inline initialization, compiler emits
before-field-init in metadata’s type definition table. When it sees a
class with explicit constructor, it doesn’t emits before-field-into
into metadata.

Now, if I have a static field in my Employee class, how would the situation differ? From what I can think, there would be 4 differnt cases

• AddEmployee is instance, class has no static constructor

• AddEmployee is instance, class has a static constructor

• AddEmployee is static, class has no static constructor

• AddEmployee is static, class has a static constructor

How would the performance differ in all these cases, assuming that method AddEmployee is called at a buttonClick and each time, an instance of employee is created (in both cases, static method or not, because they both require an instance), thus each time a new instance is created. Also, would it matter if this AddEmployee was called somewhat differently?

Answer 1

I suggest you not to use a static method in this situation. Static methods are very ugly solution in many cases. The better way will be if you create a data mapper class with instance method, it can help you in future when you decide that you need to use inheritance to extend the behavior of you data mapper class to get different saving action, for example. Don’t think about perfomance at first, especially in this moments, the experience of good programmers shows us that we need to solve the problems with perfomance when you face with it. You won’t finish your application at all if you optimize each line of code of your application. In common ways, sometimes there are 2-3 places where we need to improve perfomance of our code, but sometime there are no places of this kind at all. So, try to think about your design at first, about it readability and extensibility.