ReadOnly Reference variables in a C# Class

Question

I have a Instance Class that implements an interface and has all methods except for interface methods as static. All the class variables are static too. Two of the static variables are actually instance variables and marked as read only. These read only instance variables are initialized inline.

Here is an example

public class Test : ITestInterface
{

  public static readonly DbConnection Connection = new DbConnection();

  public void static TestMethod1(){
  }

  public List<string> static TestMethod2(){
  }

}

I have a lot of methods in my Framework layer that uses the static connection variable.

Is this a valid design? I want to use the same object for all my API calls. The idea is to avoid creating mutiple connection objects. At any given day with the load of calls from the client, there is a possibility that 10,000 connection objects can be created. I'm trying to avoid that.

Answer 1

The idea is to avoid creating mutiple connection objects

The pattern that is meant to handle that case is a Singleton pattern. Nor that you necessary have to implement in that way. But it's a general guideline.

In your concrete example, what you can do is, render ctor of a class private .

public class Test : ITestInterface
{
  ...
  private Test() {}
  ..
}

This will make creation of an instance of a class impossible, and derivation from it as well, in consequence. So the consumer of your Test class will not have other choice then access only static members of it.

But in general, I strongly encourage you to have a look on pattern linked above. It might shine some light on what you are doing and how you want to do that.

Answer 2

Few things, first of all your basically using the connection as a Singleton. This can be a perfectly fine design pattern, but there are a number of considerations, that worry me about you using it like you have posted.

1. Do you have multiple threads accessing this? Is the connection thread safe? Are all of the variables thread safe? If not you are looking for trouble.

2. Do you really want to keep one connection open for the entire life of the application? What happens if the connection gets closed? Singletons are usually a manager that handle these kinds of issues, as opposed to a single resource.

3. Do you know that the multiple connections will be inefficient? Most connection layers (Like SQL) manage a connection pool that very efficiently manage connections and do so without you having to worry about it. This is usually a better pattern unless you can prove with performance counters that you can manage the connection yourself more efficiently

I would use Singletons sparingly, and only in cases where the resource is truly global and unchanging, as well as thread safe. If it is something that is global, but needs management and thread safety wrapped around it (think connections) then you would be better off adding a custom manager class. But again, only do this if you can prove you can handle more connections and throughput manually than you can using a normal connection pool.