1

I'm currently checking a older piece of C# code used to maintain a login session.

public static ZRWebserviceSession CurrentSession { get { return _currSession; } set { _currSession = value; } }
private static ZRWebserviceSession _currSession;


public static bool IsSessionActive()
{
    if (_currentSession == null || !_currentSession.IsOpen || !_currentSession.IsLoggedIn) {
         return false;
    }
    return true;
}

I was always told using globals is bad practice and I'm looking for ways to improve this bit of code by at least getting rid of the static field used to maintain the session.

The current situation is as follows:

When the application starts the session object is initiated with a server address (taken from a config file) it should connect to. The object then retrieves the session data (token etc.) from the server to store within itself and it is then assigned to the static variable for access through the entire application. This is only done at the start of the application run or when the user explicitly restarts the session.

While a session is active other pieces of code can then call methods on the session object to retrieve the session data and make calls to the connected webservice.

Can this be improved? Is using globals still a bad practice if used for sessions or something akin to that?

EDIT: To clarify what kind of application this is: This isn't a web application but a client application that connects to a webservice. ZRWebserviceSession is a library object that represents a login session for the user currently using the client application. Kind of like the the session object of the Fabebook SDK https://developers.facebook.com/docs/reference/ios/current/class/FBSession/.

3
  • 1
    I'd argue that globals are like salt - too much will ruin the dish, but a dash here and there won't hurt. You have (presumably working) code - why muck with it? May 13, 2014 at 12:40
  • see my update example of a good use of static variables :D
    – Misters
    May 13, 2014 at 12:45
  • 1
    @DanPichelman: If globals are like salt, then that means there are many dishes that absolutely require at least a little. (Have you ever tasted bread made when someone left out the salt?)
    – DougM
    May 13, 2014 at 13:52

1 Answer 1

4

Never store sessions in a static variable!

Static variable means that when another user logs in, the static variable will be updated it with the new session and the first user will work under the last user's session. Never user static varible in a web application.

The only case where i use static variables is with constants(which are static by default);

Update:

Well a good use of static variable with session could be that when the user logs in, save the user object in session and then do this:

    var user = GetUser('username','password');

    if(user == null){
      throw new NullReferenceException("user does not exists! login failed");
   }

    else{
    Session["currentuser"] = user;

    }

So now you can do this:

public class Globals{

  public static User GetCurrentUser()
  {
     return (User)System.Web.HttpSessionStateBase["currentuser"];
  }
}

So that when you need the current user information you just call Globals.GetCurrentUser().

3
  • 1
    My apologies if I wasn't clear enough in my question. This isn't a web application but a client application that connects to a webservice. ZRWebserviceSession is a library object that represents a login session for the user currently using the client application. Kind of like the the session object of the Fabebook SDK developers.facebook.com/docs/reference/ios/current/class/…). Does the same still apply then? May 13, 2014 at 12:54
  • 1
    @LeonLucardie At that point, it is no longer a mistake, though you should avoid global static variables all the same, because it will produce horrible code that make kittens cry.
    – Neil
    May 13, 2014 at 13:02
  • thanks @Neil for helping me answering :D. LeonLucardie take at this post stackoverflow.com/questions/2671496/…
    – Misters
    May 13, 2014 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.