Where to declare class

I have a hand full of methods that interact with an instance of a class. Right now I have it initialized on the page load (its cast from a session). The code goes similar to this (simplified for the sake of an example):

protected void Page_Load(object sender, EventArgs e)
{ 
    if(!isPostBack)
    {
        MyClass myClass = (MyClass)Session["myClass"];
        myMethod1(myClass);
        myMethod1(myClass);
    }
}

private void myMethod1(MyClass class)
{
}

private void myMethod2(MyClass class)
{
}

Is this the correct way to do it, or would it be better to declare it "globaly" in the page behinds class rather than pass it from method to method.

Edit

I guess my real question is: Is there a performance drawback to passing it to me开发者_StackOverflow中文版thods (because I assume it is being reinitialized each time) vs declaring it as a public class inside the code behind's page class. If its declared public in the page's code behind then I assume it's initialized once when the page is requested.

This is a question about the scope and lifetime of the variable. A variable's "scope" is the program text in which the variable can be referenced without any qualification, and the "lifetime" is the duration for which the variable is valid.

In general, it is best to limit a variable's scope as much as possible. This makes it much easier to reason about the code.

In the example code given, there are three variables, and each of them are scoped to the individual method in which they appear. This is a good thing. Assuming the names of the methods are accurate, you can see at a glance everything that is happening with that value.

By contrast, if you increased the scope of the variable by making it a field on the Page, then all of the methods on that page would have access to the variable. It could be difficult to reason about where it is generated, how it is mutated, and what it is used for. This makes future maintenence of the application more difficult.

Therefore, my recommendation is to continue doing exactly as you have done here, whenever it is possible to do so.

EDIT

In response to the clarification of the question:

Performance is irrelivant. You are talking about nanoseconds on a web server. Web applications are constrained by traffic over the network or Internet. There will be no noticable difference in performance by any of these options about where the variable goes.

In general, performance is a question of algorithms and data structures over large collections of objects. In situations like these where there are no large data structures, then a human is not going see any difference.

Code should be designed first to be correct, understandable, and maintainable. Once that is done, then performance is only a problem if it turns out to be a problem.

Another edit

If MyClass is a class rather than a struct then the three variables in the code which are of that type are only the size of a single reference (32- or 64-bits, depending on the platform). The object to which they all refer is only created once in the code example given.

That is more of a matter of coding style and access restrictions, when you declare it as a member level of the page it is certainly not global, just local to the instance of the page object being executed.

You may want to consider other options if there is common interactions with the class across the application, like creating a session wrapper object that will handle placing/referencing the class in session and casting automatically so that you could do something along the lines of DoSomethingCool(MySessionWrapper.MyClass) etc and not have to worry about inconsistent session references across multiple classes.

I generally utilize properties to make this look cleaner as so:

protected MyClass Copy
{
   get { return Session["MyClass"] as MyClass; }
   set { Session["MyClass"] = value; }
}

Now you can just use it as needed within any of the methods in your code behind

I also have an extension method which allows me to get away from checking for null all the time.

public bool NotNull(HttpSessionState s, string key)
{
    return s[key] != null;
}

Now you could just call this when checking for null in the session:

Session.NotNull("MyClass")

There shouldn't be a problem passing the instance around as a parameter to your methods. Have you found any performance problems in your app so far? If so, they're probably in your database.

Passing objects around as parameters does not copy the entire object into another object. Only a reference to the object is passed. There is still only one instance of myClass in memory.

If a particular instance of MyClass is session specific, then yes using session is the way to go. Whether or not it should be in a session is in the details.

In general it is better to avoid globals as it they are accessible by everyone which means high coupling. This page says it better: http://c2.com/cgi/wiki?GlobalVariablesAreBad

Really, though, I would look at what myMethod[1,2] are doing. If all they are doing is accessing and manipulating the state of MyClass then they probably belong in MyClass...

You could do it this way.

public class MyPage
{
    private MyClass myClass;

    protected void Page_Load(object sender, EventArgs e)
    { 
        if(!isPostBack)
        {
            myClass = (MyClass)Session["myClass"];
            myMethod1();
            myMethod1();
        }
    }

    private void myMethod1()
    {
        // use myClass here
    }

    private void myMethod2()
    {
        // use myClass here
    }
}

The problem I see is that myClass is only assigned when it's !PostBack, so it's kind of like "is it assigned or not assigned now?" If you were always assigning myClass this tactic would make more sense to me.