The context of this question is that I am trying to debug performance issues (apart from the obvious ones I already know about and can find).
I inherited a code base (VB.NET) for an ASP.NET app. This is an app that was developed way back in .NET 1.1 days, and was the first .NET app for a lot of the developers who worked on it.
In this code base is a class called DatabaseUtility that contains several Shared Public methods as well as non-Shared Public Functions and Subs for CRUD operations to the database (SQL Server).
It is common in my "BL" that a method creates an instance of the DatabaseUtility which essentially figures out what the connection string should be and opens a connection, as well as giving the developer a handle to the other methods contained within it.
Dim utility as New DatabaseUtility()
Once I have that, I start to create parameters that I am going to pass to one of the methods in DatabaseUtility (like GetDataSet). There is a Shared method in my DatabaseUtility called CreateParameter which does essentially that. It creates a SqlParameter object so I can add it to a Parameters collection.
Now, the code base is littered with a lot of this:
utility.CreateParameter(...)
However, because CreateParameter is a Shared method, I am not sure what is going on behind the scenes. I know because it is a Shared member that an instance of the DatabaseUtility is not created when I call it like this:
DatabaseUtility.CreateParameter(...)
However, because I am calling it from an instance (utility), does that change the behavior at all?
From the VB.NET spec (my emphasis).
A shared method does not operate on a specific instance of a type and may be invoked directly from a type rather than through a particular instance of a type. It is valid, however, to use an instance to qualify a shared method.
Therefore, no, it does not matter whether you are calling it from an instance or not.