Why should I use static methods to access the database

Question

So, I ran into these problems today, and I could not find any meaningful explanation of whether there is any non-subjective reason to use static methods when it comes to interacting with databases.

Now I am working on a project where everything is done using stored procedures and, for example, I have some regular methods, for example:

public void Delete(int clientID) { //calling store procedure } 

or

 public void Save(int clientID) { //calling store procedure } 

but I also have:

 public static Client GetByID(int id) { //calling stored procedure } 

or

 public static int AddNew(string firstName, string lastName...) { //calling store procedure } 

and since I have been working with .NET about 9 months, and I use only the Entity Framework and Repository Pattern , I can’t remember anywhere or code that used static methods. Not for standard CRUD operations, nor for more specific database related tasks.

So, something has to do with how the database is accessed, it’s some kind of practice that can give (even a very small) increase in productivity, or it’s just a developers approach, and I shouldn’t give it most of the thought when and when not to use static methods in my database related methods?

Answer 1

In the specific case of the data access layer, I would avoid static methods for one simple reason ....

Static methods cannot implement the interface; instance methods can. Using static methods, you actually insist on coding the interface and instead code the implementation. Thus, everything that uses this level of data access is always required for this level of data access.

There are no alternative implementations, no test stubs, no dependency inversion at all. There is a dependency arrow in business logic that points to infrastructure (level of data access), whereas it should be the other way around.

---

In addition, it seems that this, at least, carries a great risk of having problems with the removal of resources. It may not be, but it is really easy for that. What if the developer somewhere on the road has the bright idea of ​​extracting common lines of code into the static method and property of the class? Something like a Connection object or a DBContext ? This will create very interesting and very difficult to debug runtime errors.

On the other hand, if the repositories were instances, then they can simply implement IDisposable and make sure that the objects at the class level are correctly located.

---

Continuing (I think I had more objections to design than I thought), this seems very intuitive to me from an object-oriented sense. Perhaps this is only a personal preference, but it turns what would otherwise be a "repository object" into a "dump of DB helper methods."

In such a system, I would expect that the number of random one-time methods will increase significantly over time, as developers make quick decisions to meet the requirements without thinking about the general architecture. Instead of a coherent and well-managed series of objects, you could probably get a bloated and hard-to-reach code base.

Answer 2

Static methods are used when there is no state or general state. If you have code that simply calls stored procedures, then it may not have any state except the connection string to the shared database. This would be a valid use of static methods.

Answer 3

I think your last statement is true; his approach is only to previous developers.

I will say, however, that having these static methods will make your life a nightmare for creating a test product; if you have the opportunity to change them based on the instance and create a set of unit tests that can test the application through mocks without the need for a database, this will make your life easier in the long run.

Answer 4

We very rarely use them here in our company, although they can serve purposes in utility classes or things that are just calling functions. Depending on how many instances you expect from a non-static class, they can also affect performance. But this should be a noticeable difference in instances.

source - MSDN