ASPNET putting business classes in session ?
-
My ASP.net application uses a common class I added to my App_Code folder which has all of the methods I use more than once throughout the application. Because this class is used in the masterpage, almost all site aspx pages and multiple usercontrols, I am instantiating the class multiple times in each request. I am instantiating the class in the page_load of pages and controls and then setting it to nothing on each page_unload. There is nothing in the class that needs to maintain state between requests. Is there a better way to do this or is that the normal approach? It seems so inefficient to me to be creating/destroying the class in every code behind file. I was wondering if there would be any advantage to putting the class in each users session for re-use for the lifetime of the session. I don't know if there would be any advantage to that approach or not. i was thinking of checking (each time I instantiate) if the object is in session and if not add it and if its already in session, return the object. I guess I could do that in the objects constructor. Any suggestions much appreciated Heres what I am doing in every code behind file now:
Dim c As New CommonCode()
Public ReadOnly Property C As CommonCode Get If C Is Nothing Then C = New CommonCode Return C End Get End PropertyProtected Sub btnPostComment_Click(sender As Object, e As EventArgs)
Dim name As String = IIf(txtName.Text = [String].Empty, "Anonymous", txtName.Text)
If txtComments.Text <> [String].Empty Then
c.PostComment(ID, name, txtComments.Text, RadRating.Value)
End If
End SubProtected Sub Page_Unload(sender As Object, e As System.EventArgs) Handles Me.Unload
c = Nothing
End Sub -
My ASP.net application uses a common class I added to my App_Code folder which has all of the methods I use more than once throughout the application. Because this class is used in the masterpage, almost all site aspx pages and multiple usercontrols, I am instantiating the class multiple times in each request. I am instantiating the class in the page_load of pages and controls and then setting it to nothing on each page_unload. There is nothing in the class that needs to maintain state between requests. Is there a better way to do this or is that the normal approach? It seems so inefficient to me to be creating/destroying the class in every code behind file. I was wondering if there would be any advantage to putting the class in each users session for re-use for the lifetime of the session. I don't know if there would be any advantage to that approach or not. i was thinking of checking (each time I instantiate) if the object is in session and if not add it and if its already in session, return the object. I guess I could do that in the objects constructor. Any suggestions much appreciated Heres what I am doing in every code behind file now:
Dim c As New CommonCode()
Public ReadOnly Property C As CommonCode Get If C Is Nothing Then C = New CommonCode Return C End Get End PropertyProtected Sub btnPostComment_Click(sender As Object, e As EventArgs)
Dim name As String = IIf(txtName.Text = [String].Empty, "Anonymous", txtName.Text)
If txtComments.Text <> [String].Empty Then
c.PostComment(ID, name, txtComments.Text, RadRating.Value)
End If
End SubProtected Sub Page_Unload(sender As Object, e As System.EventArgs) Handles Me.Unload
c = Nothing
End SubIMHO, you need this class and the current approach is to create it in each page. which means you are acquiring some memory and taking some time to create the object. If you keep the object in session then you will still be using than much of memory but the only advantage will be the overhead required in creating the object every-time will be gone. 1. But, in your current approach your object was being created on demand and if you keep this object in session that will like in user memory for all the time so I don't thing this is a good idea to save this in sessions. 2. Even with the overhead for creating object each time gone, you will still need the typecasting of session variables in each page which will effectively nullify the benefit we got. 3. putting this object will put some overload on session, which could mean that the session may be lost earlier than it should have(if number of request are more) and we will loose more valuable session info because we have this object residing in session memory. My recommendation would be to keep it as you have implemented. Session should only be used for the crucial information. If you need to access this info frequently then perhaps you can think about storing it in
Cacheinstead ofSession. and if it can be reused across users keep it inApplicationvariable.Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.