-1

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.

Tigran
  • 61,654
  • 8
  • 86
  • 123
Chiran
  • 1
  • 3
  • 1
    That's what connection pooling is there for. Connection objects should be short lived. Create it at the last possible moment and destroy it as soon as possible. Let the connection pooling take care of creating/pooling connections for reuse. – Kevin Sep 22 '16 at 20:04
  • This is not Sqlconnection, its a third party messaging system connection class. – Chiran Sep 22 '16 at 20:05
  • 1
    I seriously doubt this third party connection is thread safe, which would make it very hard to use correctly. Unless you really only ever call it from one thread. The other major problem you get is what should happen if the connection breaks and becomes unusable. How are you going to safely reinitialize it? – Jeroen Mostert Sep 22 '16 at 20:06
  • Doesn't matter, a database connection is a database connection regardless of the database you are hitting to. – Kevin Sep 22 '16 at 20:06
  • 1
    Who closes the connection? If it uses unmanaged resources, who disposes of it? What if you try to open an already-open connection? Is it thread-safe? These are some of the problems that static resources create. Is there a problem with thousands of connection objects being created? – D Stanley Sep 22 '16 at 20:07
  • `10,000 connection objects can be created` <= this is highly unlikely. Please see [Best Practices - Executing Sql Statements](http://stackoverflow.com/documentation/.net/3589/ado-net/14261/best-practices-executing-sql-statements). Each time you need to do something (anything) with the database create a connection and then dispose it as soon as you are done with your access. The database server will handle connection pooling for you. – Igor Sep 22 '16 at 20:09
  • Most modern messaging systems (enterprise service bus implementations) provide an API to use that should manage the connections for you. All you should need to manage is connect/send/disconnect or connect/listen semantics. – Kevin Sep 22 '16 at 20:12
  • when should we ever create a read only reference variable initialized inline – Chiran Sep 22 '16 at 20:19
  • 1
    When it's limited in scope (in this case, private) and will never enter an invalid state. And even then only when it's either thread safe, or locking is used to guarantee only one thread accesses it. Classical example: [`static readonly ILog logger = LogManager.GetLogger("name");`](https://logging.apache.org/log4net/). – Jeroen Mostert Sep 22 '16 at 20:22

2 Answers2

0

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.

Tigran
  • 61,654
  • 8
  • 86
  • 123
0

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.

Tim
  • 2,878
  • 1
  • 14
  • 19
  • My Test Class is run through application initialize feature of IIS and runs in one thread only. – Chiran Sep 22 '16 at 20:13