我应该让这个类静态吗？

Question

In the projects I worked on I have classes that query/update database, like this one,

public class CompanyInfoManager
{
    public List<string> GetCompanyNames()
    {
         //Query database and return list of company names
    }
}

as I keep creating more and more classes of this sort, I realize that maybe I should make this type of class static . By doing so the obvious benefit is avoid the need to create class instances every time I need to query the database. But since for the static class, there is only one copy of the class, will this result in hundreds of requests contend for only one copy of static class?

Thanks,

Answer 1

I would not make that class static but instead would use dependency injection and pass in needed resources to that class . This way you can create a mock repository (that implements the IRepository interface) to test with. If you make the class static and don't pass in your repository then it is very difficult to test since you can't control what the static class is connecting to.

Note: The code below is a rough example and is only intended to convey the point, not necessarily compile and execute.

public interface IRepository
{
   public DataSet ExecuteQuery(string aQuery);
   //Other methods to interact with the DB (such as update or insert) are defined here.
}

public class CompanyInfoManager
{
   private IRepository theRepository;
   public CompanyInfoManager(IRepository aRepository)
   {
      //A repository is required so that we always know what
      //we are talking to.
      theRepository = aRepository;
   }

   public List<string> GetCompanyNames()
   {
      //Query database and return list of company names
      string query = "SELECT * FROM COMPANIES";
      DataSet results = theRepository.ExecuteQuery(query);
      //Process the results...
      return listOfNames;
   }
}

To test CompanyInfoManager:

//Class to test CompanyInfoManager
public class MockRepository : IRepository
{
   //This method will always return a known value.
   public DataSet ExecuteQuery(string aQuery)
   {
      DataSet returnResults = new DataSet();
      //Fill the data set with known values...
      return returnResults;
   }
}

//This will always contain known values that you can test.
IList<string> names = new CompanyInfoManager(new MockRepository()).GetCompanyNames();

I didn't want to ramble on about dependency injection. Misko Hevery's blog goes into great detail with a great post to get started .

Answer 2

It depends. Will you ever need to make your program multithreaded? Will you ever need to connect to more than one database? Will you ever need to store state in this class? Do you need to control the lifetime of your connections? Will you need data caching in the future? If you answer yes to any of these, a static class will make things awkward.

My personal advice would be to make it an instance as this is more OO and would give you flexibility you might need in the future.

Answer 3

You have to be careful making this class static. In a web app, each request is handled on its own thread. Static utilities can be thread-unsafe if you are not careful. And if that happens you are not going to be happy.

I would highly recommend you follow the DAO pattern. Use a tool like Spring to make this easy for you. All you have to do is configure a datasource and your DB access and transactions will be a breeze.

Answer 4

If you go for a static class you will have to design it such that its largely stateless. The usual tactic is to create a base class with common data access functions and then derive them in specific classes for, say, loading Customers.

If object creation is actually the overhead in the entire operation, then you could also look at pooling pre-created objects. However, I highly doubt this is the case.

You might find that a lot of your common data access code could be made into static methods, but a static class for all data access seems like the design is lost somewhere.

Static classes don't have any issues with multi-threaded access per-se, but obviously locks and static or shared state is problematic.

Answer 5

By making the class static, you would have a hard time unit testing it, as then you would probably have to manage internally the reading of the connection string in a non-clear manner, either by reading it inside the class from a configuration file or requesting it from some class that manages these constants. I'd rather instantiate such a class in a traditional way

var manager = new CompanyInfoManager(string connectionString /*...and possible other dependencies too*/)

and then assign it to a global/public static variable, if that makes sense for the class, ie

//this can be accessed globally
public static CompanyInfoManager = manager;

so now you would not sacrifice any flexibility for your unit tests, since all of the class's dependencies are passed to it through its constructor