Neat session state trick

Just thought I'd share a neat little bit of code for handling session state in ASP.NET.

The trick is to create a class that keeps it's own sessionstate, like this:

public class CustomerSession
{
    private string mName = "";
    private string mTelephone = "";

    // To enshure unique session key
    private static string mGuid = "PlaceGUIDHere";

    public string Name
    {
        get { return mName; }
        set { mName = value; }
    }

    public string Telephone
    {
        get { return mTelephone; }
        set { mTelephone = value; }
    }

    private CustomerSession() { }

    public static CustomerSession GetInstance(HttpSessionState session)
    {
        CustomerSession o = (CustomerSession)session[mGuid];
        if(o == null) {
            o = new CustomerSession();
            session[mGuid] = o;
        }

        return o;
    }
}

Then you can save data in session like this:

protected void btnSave_Click(object sender, EventArgs e)
{
   CustomerSession data = CustomerSession.GetInstance(Session);
   data.Name = txtName.Text;
   data.Telephone = txtTelephone.Text;
}

I heard about this in .NET Rocks! episode 82 where Richard Hale Shaw where speaking of his way of storing session state in a safe way. It's at about 54 minutes into the podcast episode if you want to check it out for yourself =)

Partial classes and regions

Just read this blog post about using partial classes to separate the public interface and the private and protected members, which is a great idea.

This got me thinking of a problem I faced this week when working on using the MVP pattern for windows forms development.

One of the forms had two very distinct areas. The left side contained lists to lookup information and the right side displayed the details. This seemed to me like the perfect place to use two views. Now to implement two views in the same code-behind file you'd want some way to separate them. Regions goes some way to solving this, but it's hardly ideal. I'd much rather switch between partial classes in different files than between regions.

Now here's the issue... if you create another partial class to a windows form (in addition to the .Designer partial) the Visual Studio 2005 IDE automatically thinks it is another designer form. You would think they had thought of this scenario?

Validation logic, security and the web

I just read a blog post by Rocky Lhotka where he discusses where to put the validation logic. This interests me quite a bit because it's one of those caveats I've found around ASP.NET and web development in general.

The problem with validation in a web environment
In web projects you often want validation to take place on the client (to reduce the number of post backs and give a better user experience), but it's not an environment you can trust.

How not to do validation
For obvious reasons, as stated above, you should not exclusively put validation on the client.

One way of solving it
I would agree with Rocky Lhotka that you should put validation in the business layer to begin with, and then duplicate that to the frontend to give the user a better experience. The main point here is that the business layer will be the deciding factor what gets though no matter if the UI validation isn't working as it's intended to.

Preparing for the future
Another important point Rocky touches on is that the UI is more frequently replaced than the business layer code, which gives some value to having the validation there no matter if it's implemented in the UI.

Security
One good rule I've come across is that you should treat everything coming from the user as potentially dangerous, and even better, do the same for anything that comes from the database. With this in mind, putting at least the critical validation in the business layer seems like a good idea.

Patterns and practices?
I'm looking into ways of building robust applications by using the MVP pattern (supervising controller) and TDD. I'll probably write more about that when I've gotten a bit more experience on the subject.