Benefit of using static methods in web application

Question

I noticed in a custom base class that we use for a lot of our web pages we have a few static methods. Since the class is being used as a base class for web pages what benefit would it have making the methods static? I'm thinking none but wanted verification.

Also in custom base class we have properties that call other static methods in a manager class of ours in another class library and returns either a DataTable or HashTable. I can see where as a convenience factor for devs to code against but other than that is their any reason for making the methods static in there as well?

So existing code looks something like this:

public class CustomBaseClass
    protected Hashtable displayText
        {
            get{
                if(_displayText == null)
                    displayText = MyManager.GetCustomersList(sCustID);

since GetCustomersList is static every method inside this method has to be static as well. All the way down to our data access layer. Just seems odd to me coding it this way but was curious as to what you all thought.

Our old developers who coded our application are gone and they use them all over the place. Is their any negatives or watch out fors to using static methods especially in an asp.net app?

If I create a singleton wouldn't that make more sense, then I wouldn't have to make all the method calls right down to our DAL static? lol

Answer 1

I would say there is no advantages or disadvantages but it depends on your requirement whether you should opt static methods or not. Think of below scenarios:

• You should not use static class/members/methods: In general cases, for example - If you need to store and fetch user access information.
• You should use static methods: If you need to implement some utility methods like sending email, logging error, getting value from web.config, getting ip address of client side.

Whenever you write a function or declare a variable, it doesn’t create instance in a memory until you create object of class. But if you declare any function or variable with static modifier, it directly create instance in a memory and acts globally. The static modifier doesn’t reference with any object.

I hope this helps..

Answer 2

A better option than a singleton or a static class would be to use the Monostate Pattern.

Basically, in the Monostate Pattern, you give your static class or singleton the semantics of an ordinary class, by marking all the static members private and providing a public instance wrapper. It's a way of hiding an implementation detail, so the class gets instantiated and used just as if individual instance were being allocated on the heap.

A Monostate brings two big benefits:

• Consistent Semantics. Consumers use the monostate as they would any other class.

• Implementation Hiding. With the implementation hidden — fact that the class is static or a singleton — if and when, down the line, the class implementation needs to change, the change is limited to just the source file implementing the class. Consumers of the class are unaware of the change.

  Without the monostate, when the class implementation changes, every consumer of the class, every reference to the class or to the member being changed must be changed simultaneously, potentially a large number of source files scattered across many projects.

Here's a trivial example of a static class as a Monostate

public class MyMonostateClass
{
  #region internal, static implementation

  private static string dataItem;

  private static int someMethod( int foo )
  {
    return 0 ; // do something useful return the appropriate value
  }

  #endregion internal, static implementation

  #region public instance implementation wrappers

  public string DataItem
  {
    get { return dataItem; }
    set { dataItem = value; }
  }

  public int SomeMethod( int foo )
  {
    return MyMonostateClass.someMethod(foo);
  }

  #endregion public instance implementation wrappers

  public MyMonostateClass()
  {
    return ;
  }

}

and one of a Monostate singleton:

public class MyMonostateSingletonList : IList<int>
{
  private static readonly IList<int> instance = new List<int>() ;

  public MyMonostateSingletonList()
  {
    return ;
  }
  public int IndexOf( int item )
  {
    return instance.IndexOf(item) ;
  }
  public void Insert( int index , int item )
  {
    instance.Insert( index , item ) ;
  }
  public void RemoveAt( int index )
  {
    instance.RemoveAt( index ) ;
  }
  public int this[int index]
  {
    get
    {
      return instance[index] ;
    }
    set
    {
      instance[index] = value ;
    }
  }
  public void Add( int item )
  {
    instance.Add(item) ;
  }
  public void Clear()
  {
    instance.Clear() ;
  }
  public bool Contains( int item )
  {
    return instance.Contains(item) ;
  }
  public void CopyTo( int[] array , int arrayIndex )
  {
    instance.CopyTo( array , arrayIndex ) ;
  }
  public int Count
  {
    get { return instance.Count ; }
  }
  public bool IsReadOnly
  {
    get { return instance.IsReadOnly ; }
  }
  public bool Remove( int item )
  {
    return instance.Remove(item);
  }
  public IEnumerator<int> GetEnumerator()
  {
    return instance.GetEnumerator() ;
  }
  System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
  {
    return instance.GetEnumerator() ;
  }
}

Answer 3

The main reason to make a method static typically is when it does not depend on any instance members of the class. The avoids having to create a new instance of the class to call the method, which then needs to be garbage collected later.

Both static and instance methods obviously have their place. Typically I create static methods for utility methods that get all their state from either static members (though you have to synchronize of course) or parameters, or to set a class-wide property for all instances of the class.

You can use a singleton (though some folks hate them), or you can just have your DAO objects created at the highest level class and injected further down, of course.

The main problem with using static methods, is that while it's very easy to unit test static methods, it can be more difficult to mock the results from calls to a static DAO class. It's much easier to mock if it's an injected instance.

Answer 4

The only reason to mark something static in the context of a web application (and this question) is so that it is shared across all request threads and stays in memory. That means that if two requests are both processing and each try to set the static piece of data, you have a race condition (and threading problems potentially).

In your particular case, it seems your old developers were just lazy; there is no reason why it must be static (based on the code sample provided).