Question

I used to have a situation where I hit the database a every time I needed information on an employee. Then I taught myself about data caching and have since cleared up that problem substantially.

Now, I’d like to take it to the next level. I’d like to reduce load times by caching my object instantiation. I’m not sure that I’m being clear, so I’ll explain a little more. I have an employee object that (for example sake) has 50 properties. Some of those properties are generic lists of other related objects (such as a list of network assets belonging to that employee). So, when I instantiate an employee object for employee #30455, I don’t have to hit the database (neccessarily) because that much is cached.

BUT, I do have to run down the property list, filling them with data from datarows from the cached dataset. I also have to populate those generic lists I chose to include at the head end. Seems like I should be able to cache that object so I don’t have to do all of that over again. Thoughts?

Answer 1

One thought I have had is to instantiate employee objects using a method instead of a constructor. Then, I can do something like…

public static Employee getEmployee(int EmployeeId)
    {
        HttpContext context = HttpContext.Current;
        string key = e.ToString() + "_" + EmployeeId;

        Employee e = (Employee)context.Session[key];
        if (e == null)
        {
            e = new Employee(EmployeeId);
            context.Session[key] = e;
        }
        return e;
    }

…so that I can just…

Employee e = Employee.getEmployee(35440);

I’m already doing this in places, but I never felt like it was the best way… seems more correct to always instantiate using a constructor. Is there a better way?