I’m looking at a class handling database access for an MVC3/.Net application.
The class is static, and provides nice convenience methods for common DB queries – all sorts of twiddly stuff like “GetColumnBValueForColumnA()”, as well as much more complex queries. It’s nicely factored/optimized for the given solution and domain.
Seeing the class as static, though, triggered some half forgotten memory about how this might be a bad idea (maybe in the context of multi-threading?), and I can’t shake the feeling.
Is it a good idea to keep this kind of class static, or should I be instantiating it for each database call?
If you care about things like weak coupling between the layers of your application, reusability of those layers, unit testing in isolation you shouldn’t be doing any of the above. You should be working with abstractions.
If you don’t care about those things then static methods are just fine. The only thing to be careful when working with static methods is to design them so that they are reentrant and do not depend on any shared state in order to be thread safe. In all cases make sure to properly dispose all IDisposable resources such as database connections and commands by wrapping them in using statements.