What to do with my collection objects...


I have imported several collection objects from my class library into my asp.net app (C#).  Let's say I have an EmployeeCol, DepartmentCol collection objects and I use those same objects as my dataSource for my DropDownList boxes.

Whenever I choose as Department via the dropdownListBox, the Employee dropdownlistbox will show all the employees for the currently selected department.  

Anyways, whenever the page is posting back, my EmployeeCol and DepartmentCol are set to null and I will have to re-instantiate them on the page_load event and fill my objects with the appropriate objects.  

What I am wondering about whether it's common practice to assign a collection object into the session variable?  I suppose it would be a performance hit having to cast it back into the appropriate type but would be offset by not having to creating objects and not talking to the database but not sure on that.

Hope this post made somewhat sense...if not please feel free to ask questions, comments, suggestions...etc.


Who is Participating?
RogerSTHLMConnect With a Mentor Commented:

I guess this is the top question in any web dev - what do I keep it stateless and what do I place in some sort of cache mechanism? For sure there is no overall answer. It depends on different things, how large are your collections, how cpu intensive is it to reread the data, how important is it with totally accurate data, what's your bandwith capacity between your webserver and datasource etc etc.

Yes. What I meant with "application wide caching" is just what you write. And yes - the problems you mention is completly true.
I guess 98% of every web developer just using the session object to cache things (and of course using view state for the controls). I just wanted to stress that if you want to do things properly, here is one thing to optimize your app a lot. If you have 1000 users accessing your site, it's of course a huge improvement to cache objects one time than thousand. But sometimes it isn't possible or not just worth the effort.

Some examples...
* Readonly data or "almost read only" data. If you want to cache this type of data (eg a list of countries used for registration forms etc etc), it's simple and much better to cache it "one time".
* Custom collection. If you have something unique in every object (eg a guid), you can cache them "application wide". When you call GetPersonById(byval id as guid), you check if your object exists in the cache. If you update the Person, you remove it from the cache. If you don't have any guids or something like that, but just using eg integers, you can have "one cache" for every type of object.
The problem occur when you not get your objects by id, but for example getting all Persons with a first name starting with an "a". It's much harder to get those thing working. You probably must have all your db in the web server's RAM, and that's not just possible (at least not in 99% of the cases). If you need this type of data, you need to cache it per user. If you use a statebag (=viewstate) or using the web server's RAM I guess is a matter of taste and a matter of hardware (a lot of RAM, bandwith to your clients etc). But I would start looking at using the viewstate. One thing to mention here, is that you need to serialize your objects to be able to put them in the viewstate.

Finally, if you are using asp.net...
Cache something "application wide":
Look at the Cache object in .net framework

When you need to cache something per user:
Session var - iis ram
Statebag (viewstate("foo")=obj2cache) - serialized and sent between server and client
Another "session way" - cache("foo" +session.sessionid)=obj2cache - would work similar to a session variable, but you have the good things with the cache obj like dependencies etc. Be sure to remove it when the session ends though.

brdrokAuthor Commented:
below is some of my code:

public class AddOrders : System.Web.UI.Page
   private SWOLBL.ProjectCollection projectCol;
   private SWOLBL.ContractTypeCollection cTypeCol;

   private void Page_Load(object sender, System.EventArgs e)
       cTypeCol = new ContractTypeCollection();
        //fill my collection object with contract type objects
      //project collection
      projectCol = new ProjectCollection();
        //fill my collection object with project objects

        if (!Page.IsPostBack)
             //do some initialization stuff here

private void ddlContractType_SelectedIndexChanged(object sender, System.EventArgs e)
      if (ddlContractType.SelectedIndex > 0)
            ddlTask.Enabled = true;
            ddlTask.DataSource = null;
            ddlTask.DataSource = cTypeCol[ddlContractType.SelectedIndex - 1].TaskCollection;
            ddlTask.DataTextField = "Name";
            ddlTask.DataValueField = "ID";
            ddlTask.Items.Insert(0, "Select Task...");

there has to be a better way than having to re-create my objects on eveyr post back
Using custom collections are no diffent than using eg a dataset. The part of your collection that are bound to the control's datasource is (by default) hold in its viewstate. As with a dataset, the collection itself is destroyed when the request has ended.

If you need to hold a state for your collection (not only the properties that's bound to the control), you can do it in several ways. In a statebag (you need to serialize your objects in that case), session variable (which I personally don't like... really a waste of RAM) or use some sort of "application wide cache" (=eg using the cache object).

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

brdrokAuthor Commented:
thanks very much for the reply....

the one thing I am wondering is whether it's better to re-create those objects (i.e. dataSets or collection objects) on each post-back or stick 'em into an application wide cache?  Also, if I understand application wide cache correctly, if User A and User B are logged on at the same time, does that mean that both will be using the same collection object/dataSet?  Could there be a possible concurrency issue be involved when going that route?

brdrokAuthor Commented:
thanks....awesome answers.  

the points are yours.  was hoping that there would be an easier solution but if it were easy one couldn't justify the salary :)

but will look into application wide cache...do you happened to know of any good links that show how to do that?

Should maybe have mentioned when talking about caching... An easy way to get HUGE impovement in performance is using asp.net page (and/or user control) cache. I guess this won't help you with your first question but... This will cache your rendered html pages in different ways. If this isn't familiar to you, have a look in your .net framework doc.

Nope. Sorry. I have no good links. I guess you have to google.

Friday! Time to party in Stockholm!

Good luck!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.