How do you figure out how much memory a class is using?

I would like to know how you can figure out how much memory a given instance
of a class is using.

For example, if I load a collection class with 10 items it might use 1KB,
and if I load it with 1000 items it might use 100KB.
How do I measure the amount of memory used once the class is loaded?

Thanks!
--
Joe Fallon

re: How do you figure out how much memory a class is using?

* "Joe Fallon" <jfallon1@nospamtwcny.rr.com> scripsit:[color=blue]
> I would like to know how you can figure out how much memory a given instance
> of a class is using.
>
> For example, if I load a collection class with 10 items it might use 1KB,
> and if I load it with 1000 items it might use 100KB.
> How do I measure the amount of memory used once the class is loaded?[/color]

All you can do is using a memory profiler. I am not sure if this will
work as you expect it to do.

<URL:http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=3254325d-a4aa-4bb3-aa86-c72d5104ec74>

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

re: How do you figure out how much memory a class is using?

Herfried,
Thanks for the response.

I am trying code like this:
(Appreciate any comments.)

Dim byteCount As Long = System.GC.GetTotalMemory(False)
mCollection = Collection.GetCollection()

byteCount = System.GC.GetTotalMemory(False) - byteCount

Dim Collectionkb As Double = byteCount / 1024

I ran this code a few times in a row and got varying answers.
65KB, 59KB, 43KB, 47KB, 47KB, 48KB

When I serialize the class to a file on disk it is 30KB.
I thought the rule of thumb was that File size x 2 = Size in Memory.

Can you think of a more reliable way to determine the amount of RAM used by
a class at runtime?
I am trying to decide if I should keep the collection in RAM or serialize it
to disk.
I would like to decide this at run time based on it exceeding a certain
amount of RAM.
--
Joe Fallon



"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:c6ol01$eeqgs$3@ID-208219.news.uni-berlin.de...[color=blue]
> * "Joe Fallon" <jfallon1@nospamtwcny.rr.com> scripsit:[color=green]
> > I would like to know how you can figure out how much memory a given[/color][/color]
instance[color=blue][color=green]
> > of a class is using.
> >
> > For example, if I load a collection class with 10 items it might use[/color][/color]
1KB,[color=blue][color=green]
> > and if I load it with 1000 items it might use 100KB.
> > How do I measure the amount of memory used once the class is loaded?[/color]
>
> All you can do is using a memory profiler. I am not sure if this will
> work as you expect it to do.
>
>[/color]
<URL:http://www.gotdotnet.com/Community/U...px?SampleGuid=
3254325d-a4aa-4bb3-aa86-c72d5104ec74>[color=blue]
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>[/color]

re: How do you figure out how much memory a class is using?

Joe,[color=blue]
> When I serialize the class to a file on disk it is 30KB.
> I thought the rule of thumb was that File size x 2 = Size in Memory.[/color]
Look at what is actually serialized, there is extra overhead in binary
serialization, as it stores Type & property names in the stream.
[color=blue]
> I am trying to decide if I should keep the collection in RAM or serialize[/color]
it[color=blue]
> to disk.
> I would like to decide this at run time based on it exceeding a certain
> amount of RAM.[/color]
Are the individual elements a fixed size? I would have a config threshold
option for number of elements, if the collection hits the number of elements
I would go to disk, otherwise I would keep it in memory...

Hope this helps
Jay

"Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
news:%232mLs3TLEHA.1348@TK2MSFTNGP12.phx.gbl...[color=blue]
> Herfried,
> Thanks for the response.
>
> I am trying code like this:
> (Appreciate any comments.)
>
> Dim byteCount As Long = System.GC.GetTotalMemory(False)
> mCollection = Collection.GetCollection()
>
> byteCount = System.GC.GetTotalMemory(False) - byteCount
>
> Dim Collectionkb As Double = byteCount / 1024
>
> I ran this code a few times in a row and got varying answers.
> 65KB, 59KB, 43KB, 47KB, 47KB, 48KB
>
> When I serialize the class to a file on disk it is 30KB.
> I thought the rule of thumb was that File size x 2 = Size in Memory.
>
> Can you think of a more reliable way to determine the amount of RAM used[/color]
by[color=blue]
> a class at runtime?
> I am trying to decide if I should keep the collection in RAM or serialize[/color]
it[color=blue]
> to disk.
> I would like to decide this at run time based on it exceeding a certain
> amount of RAM.
> --
> Joe Fallon
>
>
>
> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> news:c6ol01$eeqgs$3@ID-208219.news.uni-berlin.de...[color=green]
> > * "Joe Fallon" <jfallon1@nospamtwcny.rr.com> scripsit:[color=darkred]
> > > I would like to know how you can figure out how much memory a given[/color][/color]
> instance[color=green][color=darkred]
> > > of a class is using.
> > >
> > > For example, if I load a collection class with 10 items it might use[/color][/color]
> 1KB,[color=green][color=darkred]
> > > and if I load it with 1000 items it might use 100KB.
> > > How do I measure the amount of memory used once the class is loaded?[/color]
> >
> > All you can do is using a memory profiler. I am not sure if this will
> > work as you expect it to do.
> >
> >[/color]
>[/color]
<URL:http://www.gotdotnet.com/Community/U...px?SampleGuid=[color=blue]
> 3254325d-a4aa-4bb3-aa86-c72d5104ec74>[color=green]
> >
> > --
> > Herfried K. Wagner [MVP]
> > <URL:http://dotnet.mvps.org/>[/color]
>
>[/color]

re: How do you figure out how much memory a class is using?

Joe,
There is no way to get the size of a managed object per se.

You could use System.Runtime.InteropServices.Marshal.SizeOf, however this
returns the size of the object when it is marshaled to the unmanaged world,
it does not report the true size of the object in the managed realm.

Also I do not believe the Marshal.SizeOf method takes into account
collection classes, you could use the enumerator of the class to get the
size of each element, unfortunately this will not give you a good idea of
any overhead in the management of the collection...

Hope this helps
Jay

"Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
news:OFEVVETLEHA.3548@TK2MSFTNGP10.phx.gbl...[color=blue]
> I would like to know how you can figure out how much memory a given[/color]
instance[color=blue]
> of a class is using.
>
> For example, if I load a collection class with 10 items it might use 1KB,
> and if I load it with 1000 items it might use 100KB.
> How do I measure the amount of memory used once the class is loaded?
>
> Thanks!
> --
> Joe Fallon
>
>
>
>[/color]

re: How do you figure out how much memory a class is using?

Jay,
It helps a lot.

I tried System.Runtime.InteropServices.Marshal.SizeOf on one of my classes
and it failed.

Now that I know it is basically "impossible" I can stop going down that
path.

I decided to use a web.config appsetting flag for this.
When the flag is False then I use Session to store the collection.
When it is True, I will serialize the collection to disk instead.

I only plan to do this for potentially large objects.
Smaller ones will be tossed into Session or Viewstate.

So instead of the normal 2 lines of code (1 to put the object into Session
and 1 to take it out)
I just wrap them in an If statement and check the flag.

So by default, we will store things in Session, but in a pinch can move
large objects to disk and back.
I guess that is a workable approach.

(My original goal was to dynamically test the size of the object and if it
crossed a threshold to move it to disk.)

Thanks for the help Jay!

--
Joe Fallon
Access MVP



"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:uXAAVjYLEHA.2692@tk2msftngp13.phx.gbl...[color=blue]
> Joe,
> There is no way to get the size of a managed object per se.
>
> You could use System.Runtime.InteropServices.Marshal.SizeOf, however this
> returns the size of the object when it is marshaled to the unmanaged[/color]
world,[color=blue]
> it does not report the true size of the object in the managed realm.
>
> Also I do not believe the Marshal.SizeOf method takes into account
> collection classes, you could use the enumerator of the class to get the
> size of each element, unfortunately this will not give you a good idea of
> any overhead in the management of the collection...
>
> Hope this helps
> Jay
>
> "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> news:OFEVVETLEHA.3548@TK2MSFTNGP10.phx.gbl...[color=green]
> > I would like to know how you can figure out how much memory a given[/color]
> instance[color=green]
> > of a class is using.
> >
> > For example, if I load a collection class with 10 items it might use[/color][/color]
1KB,[color=blue][color=green]
> > and if I load it with 1000 items it might use 100KB.
> > How do I measure the amount of memory used once the class is loaded?
> >
> > Thanks!
> > --
> > Joe Fallon
> >
> >
> >
> >[/color]
>
>[/color]

re: How do you figure out how much memory a class is using?

Joe,[color=blue]
> So instead of the normal 2 lines of code (1 to put the object into Session
> and 1 to take it out)
> I just wrap them in an If statement and check the flag.[/color]
I hope you encapsulated your If in a property in a well known place.

In fact I normally encapsulate all access to Session, Viewstate, Cache,
Application, & etc variables in properties in a well known place. This
allows a "single" point of change if I decide that Cache is better then
Session for the variable...

This well known place could either be a shared property of a domain class
(causes coupling to ASP.NET) or a base Page or Control class in ASP.NET. I
normally go for the base Page or Control class, although the domain class
makes its easier (the property is in a single place, verses two places).
Note there are ways to mitigate the coupling to ASP.NET if you choose to put
the property in the domain class...

Hope this helps
Jay



"Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
news:uUKCEeZLEHA.628@TK2MSFTNGP11.phx.gbl...[color=blue]
> Jay,
> It helps a lot.
>
> I tried System.Runtime.InteropServices.Marshal.SizeOf on one of my classes
> and it failed.
>
> Now that I know it is basically "impossible" I can stop going down that
> path.
>
> I decided to use a web.config appsetting flag for this.
> When the flag is False then I use Session to store the collection.
> When it is True, I will serialize the collection to disk instead.
>
> I only plan to do this for potentially large objects.
> Smaller ones will be tossed into Session or Viewstate.
>
> So instead of the normal 2 lines of code (1 to put the object into Session
> and 1 to take it out)
> I just wrap them in an If statement and check the flag.
>
> So by default, we will store things in Session, but in a pinch can move
> large objects to disk and back.
> I guess that is a workable approach.
>
> (My original goal was to dynamically test the size of the object and if it
> crossed a threshold to move it to disk.)
>
> Thanks for the help Jay!
>
> --
> Joe Fallon
> Access MVP
>
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:uXAAVjYLEHA.2692@tk2msftngp13.phx.gbl...[color=green]
> > Joe,
> > There is no way to get the size of a managed object per se.
> >
> > You could use System.Runtime.InteropServices.Marshal.SizeOf, however[/color][/color]
this[color=blue][color=green]
> > returns the size of the object when it is marshaled to the unmanaged[/color]
> world,[color=green]
> > it does not report the true size of the object in the managed realm.
> >
> > Also I do not believe the Marshal.SizeOf method takes into account
> > collection classes, you could use the enumerator of the class to get the
> > size of each element, unfortunately this will not give you a good idea[/color][/color]
of[color=blue][color=green]
> > any overhead in the management of the collection...
> >
> > Hope this helps
> > Jay
> >
> > "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> > news:OFEVVETLEHA.3548@TK2MSFTNGP10.phx.gbl...[color=darkred]
> > > I would like to know how you can figure out how much memory a given[/color]
> > instance[color=darkred]
> > > of a class is using.
> > >
> > > For example, if I load a collection class with 10 items it might use[/color][/color]
> 1KB,[color=green][color=darkred]
> > > and if I load it with 1000 items it might use 100KB.
> > > How do I measure the amount of memory used once the class is loaded?
> > >
> > > Thanks!
> > > --
> > > Joe Fallon
> > >
> > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

re: How do you figure out how much memory a class is using?

Jay,
That is very interesting.
Session, Viewstate, Cache, Application,

Can you elaborate on how you control these with some sample code?

I am sure it is not an "all or nothing" solution. You must be able to
control a given variable (like my large collection) using any one of
Session, Viewstate, Cache, Application. I would like to see how you do it so
I don't go down the wrong path again!

Thanks for another good idea!

--
Joe Fallon



"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:uRivVYeLEHA.2716@tk2msftngp13.phx.gbl...[color=blue]
> Joe,[color=green]
> > So instead of the normal 2 lines of code (1 to put the object into[/color][/color]
Session[color=blue][color=green]
> > and 1 to take it out)
> > I just wrap them in an If statement and check the flag.[/color]
> I hope you encapsulated your If in a property in a well known place.
>
> In fact I normally encapsulate all access to Session, Viewstate, Cache,
> Application, & etc variables in properties in a well known place. This
> allows a "single" point of change if I decide that Cache is better then
> Session for the variable...
>
> This well known place could either be a shared property of a domain class
> (causes coupling to ASP.NET) or a base Page or Control class in ASP.NET. I
> normally go for the base Page or Control class, although the domain class
> makes its easier (the property is in a single place, verses two places).
> Note there are ways to mitigate the coupling to ASP.NET if you choose to[/color]
put[color=blue]
> the property in the domain class...
>
> Hope this helps
> Jay
>
>
>
> "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> news:uUKCEeZLEHA.628@TK2MSFTNGP11.phx.gbl...[color=green]
> > Jay,
> > It helps a lot.
> >
> > I tried System.Runtime.InteropServices.Marshal.SizeOf on one of my[/color][/color]
classes[color=blue][color=green]
> > and it failed.
> >
> > Now that I know it is basically "impossible" I can stop going down that
> > path.
> >
> > I decided to use a web.config appsetting flag for this.
> > When the flag is False then I use Session to store the collection.
> > When it is True, I will serialize the collection to disk instead.
> >
> > I only plan to do this for potentially large objects.
> > Smaller ones will be tossed into Session or Viewstate.
> >
> > So instead of the normal 2 lines of code (1 to put the object into[/color][/color]
Session[color=blue][color=green]
> > and 1 to take it out)
> > I just wrap them in an If statement and check the flag.
> >
> > So by default, we will store things in Session, but in a pinch can move
> > large objects to disk and back.
> > I guess that is a workable approach.
> >
> > (My original goal was to dynamically test the size of the object and if[/color][/color]
it[color=blue][color=green]
> > crossed a threshold to move it to disk.)
> >
> > Thanks for the help Jay!
> >
> > --
> > Joe Fallon
> > Access MVP
> >
> >
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:uXAAVjYLEHA.2692@tk2msftngp13.phx.gbl...[color=darkred]
> > > Joe,
> > > There is no way to get the size of a managed object per se.
> > >
> > > You could use System.Runtime.InteropServices.Marshal.SizeOf, however[/color][/color]
> this[color=green][color=darkred]
> > > returns the size of the object when it is marshaled to the unmanaged[/color]
> > world,[color=darkred]
> > > it does not report the true size of the object in the managed realm.
> > >
> > > Also I do not believe the Marshal.SizeOf method takes into account
> > > collection classes, you could use the enumerator of the class to get[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > size of each element, unfortunately this will not give you a good idea[/color][/color]
> of[color=green][color=darkred]
> > > any overhead in the management of the collection...
> > >
> > > Hope this helps
> > > Jay
> > >
> > > "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> > > news:OFEVVETLEHA.3548@TK2MSFTNGP10.phx.gbl...
> > > > I would like to know how you can figure out how much memory a given
> > > instance
> > > > of a class is using.
> > > >
> > > > For example, if I load a collection class with 10 items it might use[/color]
> > 1KB,[color=darkred]
> > > > and if I load it with 1000 items it might use 100KB.
> > > > How do I measure the amount of memory used once the class is loaded?
> > > >
> > > > Thanks!
> > > > --
> > > > Joe Fallon
> > > >
> > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

re: How do you figure out how much memory a class is using?

Joe,
Basically its an extension of the Encapsulate Downcast refactoring.
http://www.refactoring.com/catalog/e...eDowncast.html

Rather then have the DirectCast of Session variables scattered throughout my
code, I encapsulate the downcast into a property, normally in a base class.

Normally something like:

' in PageBase.vb file
Public Class PageBase
Inherits System.Web.UI.Page

Public Property ShoppingCart() As ShoppingCartDataSet
Get
Return DirectCast(Session("ShoppingCart"),
ShoppingCartDataSet)
End Get
Set(ByVal value As ShoppingCartDataSet)
Session("ShoppingCart") = value
End Set
End Property

End Class


' in WebForm1.aspx.vb
Public Class WebForm1
Inherits PageBase

Private Sub Page_Load(...) Handles MyBase.Load
DataGrid1.DataSource = Mybase.ShoppingCart.Items
DataGrid1.DataBind()
End Sub

End Class

' in WebForm1.aspx
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="WebForm1.aspx.vb"
Inherits="SampleWebApp.WebForm1" %>


Where ShoppingCartDataSet is a typed dataset that represents the shopping
cart.

Benefits of the above include, but are not limited to:
- Session Variable name is in a single location
- Easy to change from Session to Cache or Disk & back
- Downcast is in a single location
- Enables dynamic creation, the Get could create & initialize the Session
variable if it did not already exist
- The code that consumes the Session variable is cleaner (there is no
downcast & checks)

If your case, the check of the web.config setting would be in a single spot,
the property's Get & Set methods.

Even if the Session variable is used in a single location I would probably
apply the same pattern, as invariable the session variable winds up being
used in multiple places, its more consistent with other code, and it
promotes "cleaner" code.

Hope this helps
Jay

"Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
news:%23HN%23ngeLEHA.1192@TK2MSFTNGP11.phx.gbl...[color=blue]
> Jay,
> That is very interesting.
> Session, Viewstate, Cache, Application,
>
> Can you elaborate on how you control these with some sample code?
>
> I am sure it is not an "all or nothing" solution. You must be able to
> control a given variable (like my large collection) using any one of
> Session, Viewstate, Cache, Application. I would like to see how you do it[/color]
so[color=blue]
> I don't go down the wrong path again!
>
> Thanks for another good idea!
>
> --
> Joe Fallon
>
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:uRivVYeLEHA.2716@tk2msftngp13.phx.gbl...[color=green]
> > Joe,[color=darkred]
> > > So instead of the normal 2 lines of code (1 to put the object into[/color][/color]
> Session[color=green][color=darkred]
> > > and 1 to take it out)
> > > I just wrap them in an If statement and check the flag.[/color]
> > I hope you encapsulated your If in a property in a well known place.
> >
> > In fact I normally encapsulate all access to Session, Viewstate, Cache,
> > Application, & etc variables in properties in a well known place. This
> > allows a "single" point of change if I decide that Cache is better then
> > Session for the variable...
> >
> > This well known place could either be a shared property of a domain[/color][/color]
class[color=blue][color=green]
> > (causes coupling to ASP.NET) or a base Page or Control class in ASP.NET.[/color][/color]
I[color=blue][color=green]
> > normally go for the base Page or Control class, although the domain[/color][/color]
class[color=blue][color=green]
> > makes its easier (the property is in a single place, verses two places).
> > Note there are ways to mitigate the coupling to ASP.NET if you choose to[/color]
> put[color=green]
> > the property in the domain class...
> >
> > Hope this helps
> > Jay
> >[/color][/color]
<<snip>>

re: How do you figure out how much memory a class is using?

Doh!
I should add: All web forms within my web app would inherit from the
PageBase class, as I showed for WebForm1.

Hope this helps
Jay

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:Odkw72eLEHA.2244@tk2msftngp13.phx.gbl...[color=blue]
> Joe,
> Basically its an extension of the Encapsulate Downcast refactoring.
> http://www.refactoring.com/catalog/e...eDowncast.html
>
> Rather then have the DirectCast of Session variables scattered throughout[/color]
my[color=blue]
> code, I encapsulate the downcast into a property, normally in a base[/color]
class.[color=blue]
>
> Normally something like:
>
> ' in PageBase.vb file
> Public Class PageBase
> Inherits System.Web.UI.Page
>
> Public Property ShoppingCart() As ShoppingCartDataSet
> Get
> Return DirectCast(Session("ShoppingCart"),
> ShoppingCartDataSet)
> End Get
> Set(ByVal value As ShoppingCartDataSet)
> Session("ShoppingCart") = value
> End Set
> End Property
>
> End Class
>
>
> ' in WebForm1.aspx.vb
> Public Class WebForm1
> Inherits PageBase
>
> Private Sub Page_Load(...) Handles MyBase.Load
> DataGrid1.DataSource = Mybase.ShoppingCart.Items
> DataGrid1.DataBind()
> End Sub
>
> End Class
>
> ' in WebForm1.aspx
> <%@ Page Language="vb" AutoEventWireup="false"[/color]
Codebehind="WebForm1.aspx.vb"[color=blue]
> Inherits="SampleWebApp.WebForm1" %>
>
>
> Where ShoppingCartDataSet is a typed dataset that represents the shopping
> cart.
>
> Benefits of the above include, but are not limited to:
> - Session Variable name is in a single location
> - Easy to change from Session to Cache or Disk & back
> - Downcast is in a single location
> - Enables dynamic creation, the Get could create & initialize the Session
> variable if it did not already exist
> - The code that consumes the Session variable is cleaner (there is no
> downcast & checks)
>
> If your case, the check of the web.config setting would be in a single[/color]
spot,[color=blue]
> the property's Get & Set methods.
>
> Even if the Session variable is used in a single location I would probably
> apply the same pattern, as invariable the session variable winds up being
> used in multiple places, its more consistent with other code, and it
> promotes "cleaner" code.
>
> Hope this helps
> Jay
>
> "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> news:%23HN%23ngeLEHA.1192@TK2MSFTNGP11.phx.gbl...[color=green]
> > Jay,
> > That is very interesting.
> > Session, Viewstate, Cache, Application,
> >
> > Can you elaborate on how you control these with some sample code?
> >
> > I am sure it is not an "all or nothing" solution. You must be able to
> > control a given variable (like my large collection) using any one of
> > Session, Viewstate, Cache, Application. I would like to see how you do[/color][/color]
it[color=blue]
> so[color=green]
> > I don't go down the wrong path again!
> >
> > Thanks for another good idea!
> >
> > --
> > Joe Fallon
> >
> >
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:uRivVYeLEHA.2716@tk2msftngp13.phx.gbl...[color=darkred]
> > > Joe,
> > > > So instead of the normal 2 lines of code (1 to put the object into[/color]
> > Session[color=darkred]
> > > > and 1 to take it out)
> > > > I just wrap them in an If statement and check the flag.
> > > I hope you encapsulated your If in a property in a well known place.
> > >
> > > In fact I normally encapsulate all access to Session, Viewstate,[/color][/color][/color]
Cache,[color=blue][color=green][color=darkred]
> > > Application, & etc variables in properties in a well known place. This
> > > allows a "single" point of change if I decide that Cache is better[/color][/color][/color]
then[color=blue][color=green][color=darkred]
> > > Session for the variable...
> > >
> > > This well known place could either be a shared property of a domain[/color][/color]
> class[color=green][color=darkred]
> > > (causes coupling to ASP.NET) or a base Page or Control class in[/color][/color][/color]
ASP.NET.[color=blue]
> I[color=green][color=darkred]
> > > normally go for the base Page or Control class, although the domain[/color][/color]
> class[color=green][color=darkred]
> > > makes its easier (the property is in a single place, verses two[/color][/color][/color]
places).[color=blue][color=green][color=darkred]
> > > Note there are ways to mitigate the coupling to ASP.NET if you choose[/color][/color][/color]
to[color=blue][color=green]
> > put[color=darkred]
> > > the property in the domain class...
> > >
> > > Hope this helps
> > > Jay
> > >[/color][/color]
> <<snip>>
>
>[/color]

re: How do you figure out how much memory a class is using?

Hi Joe,

Are you sure you are not going in that dead ending road, wherefore load
balancing is invented?

Just my thought?

Cor

re: How do you figure out how much memory a class is using?

Hi Cor,
No I am not sure! <g>

I agree that load balancing is very valuable.
It is part of the overall design of the app.
All of our Business Objects are Serializable and we can use a StateServer
for a Web Farm.

I am just looking for a way to trade off RAM for "time to serialize to/from
disk" to minimize the impact of large objects on the Session state server
memory.
--
Joe Fallon



"Cor Ligthert" <notfirstname@planet.nl> wrote in message
news:ucSgRdfLEHA.2100@TK2MSFTNGP10.phx.gbl...[color=blue]
> Hi Joe,
>
> Are you sure you are not going in that dead ending road, wherefore load
> balancing is invented?
>
> Just my thought?
>
> Cor
>
>[/color]

re: How do you figure out how much memory a class is using?

Jay,
I have a Page base class for my app so what you are saying makes sense.

Since I could have dozens (or hundreds) of Business Objects, do you think
the idea of using a Property for each one of them makes sense in the Base
class or should I have a Property on the given page that consumes the BO?

Also, I noted that in the sample Property there was just the use of Session.
Are you saying that you would just edit the Property and change it to
Viewstate if you wanted to change how it is stored?
But wouldn't that require you to re-compile and re-distribute the
application .dll?

I am wondering if it makes sense to be more "configurable" and set flags in
web.config and then use SelectCase in the Property Get/Set to determine the
value of the flag and implement any of these:
Application, Cache, Session, Viewstate.

Then a client who is low on RAM could switch the flag in web.config from
UseSession to UseFiles (or somethinng like that - maybe an Enum) and the app
would behave differently without a re-compilation.

What do you think?
--
Joe Fallon



"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:#K0NiSfLEHA.3684@TK2MSFTNGP12.phx.gbl...[color=blue]
> Doh!
> I should add: All web forms within my web app would inherit from the
> PageBase class, as I showed for WebForm1.
>
> Hope this helps
> Jay
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:Odkw72eLEHA.2244@tk2msftngp13.phx.gbl...[color=green]
> > Joe,
> > Basically its an extension of the Encapsulate Downcast refactoring.
> > http://www.refactoring.com/catalog/e...eDowncast.html
> >
> > Rather then have the DirectCast of Session variables scattered[/color][/color]
throughout[color=blue]
> my[color=green]
> > code, I encapsulate the downcast into a property, normally in a base[/color]
> class.[color=green]
> >
> > Normally something like:
> >
> > ' in PageBase.vb file
> > Public Class PageBase
> > Inherits System.Web.UI.Page
> >
> > Public Property ShoppingCart() As ShoppingCartDataSet
> > Get
> > Return DirectCast(Session("ShoppingCart"),
> > ShoppingCartDataSet)
> > End Get
> > Set(ByVal value As ShoppingCartDataSet)
> > Session("ShoppingCart") = value
> > End Set
> > End Property
> >
> > End Class
> >
> >
> > ' in WebForm1.aspx.vb
> > Public Class WebForm1
> > Inherits PageBase
> >
> > Private Sub Page_Load(...) Handles MyBase.Load
> > DataGrid1.DataSource = Mybase.ShoppingCart.Items
> > DataGrid1.DataBind()
> > End Sub
> >
> > End Class
> >
> > ' in WebForm1.aspx
> > <%@ Page Language="vb" AutoEventWireup="false"[/color]
> Codebehind="WebForm1.aspx.vb"[color=green]
> > Inherits="SampleWebApp.WebForm1" %>
> >
> >
> > Where ShoppingCartDataSet is a typed dataset that represents the[/color][/color]
shopping[color=blue][color=green]
> > cart.
> >
> > Benefits of the above include, but are not limited to:
> > - Session Variable name is in a single location
> > - Easy to change from Session to Cache or Disk & back
> > - Downcast is in a single location
> > - Enables dynamic creation, the Get could create & initialize the[/color][/color]
Session[color=blue][color=green]
> > variable if it did not already exist
> > - The code that consumes the Session variable is cleaner (there is no
> > downcast & checks)
> >
> > If your case, the check of the web.config setting would be in a single[/color]
> spot,[color=green]
> > the property's Get & Set methods.
> >
> > Even if the Session variable is used in a single location I would[/color][/color]
probably[color=blue][color=green]
> > apply the same pattern, as invariable the session variable winds up[/color][/color]
being[color=blue][color=green]
> > used in multiple places, its more consistent with other code, and it
> > promotes "cleaner" code.
> >
> > Hope this helps
> > Jay
> >
> > "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> > news:%23HN%23ngeLEHA.1192@TK2MSFTNGP11.phx.gbl...[color=darkred]
> > > Jay,
> > > That is very interesting.
> > > Session, Viewstate, Cache, Application,
> > >
> > > Can you elaborate on how you control these with some sample code?
> > >
> > > I am sure it is not an "all or nothing" solution. You must be able to
> > > control a given variable (like my large collection) using any one of
> > > Session, Viewstate, Cache, Application. I would like to see how you do[/color][/color]
> it[color=green]
> > so[color=darkred]
> > > I don't go down the wrong path again!
> > >
> > > Thanks for another good idea!
> > >
> > > --
> > > Joe Fallon
> > >
> > >
> > >
> > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
> message[color=green][color=darkred]
> > > news:uRivVYeLEHA.2716@tk2msftngp13.phx.gbl...
> > > > Joe,
> > > > > So instead of the normal 2 lines of code (1 to put the object into
> > > Session
> > > > > and 1 to take it out)
> > > > > I just wrap them in an If statement and check the flag.
> > > > I hope you encapsulated your If in a property in a well known place.
> > > >
> > > > In fact I normally encapsulate all access to Session, Viewstate,[/color][/color]
> Cache,[color=green][color=darkred]
> > > > Application, & etc variables in properties in a well known place.[/color][/color][/color]
This[color=blue][color=green][color=darkred]
> > > > allows a "single" point of change if I decide that Cache is better[/color][/color]
> then[color=green][color=darkred]
> > > > Session for the variable...
> > > >
> > > > This well known place could either be a shared property of a domain[/color]
> > class[color=darkred]
> > > > (causes coupling to ASP.NET) or a base Page or Control class in[/color][/color]
> ASP.NET.[color=green]
> > I[color=darkred]
> > > > normally go for the base Page or Control class, although the domain[/color]
> > class[color=darkred]
> > > > makes its easier (the property is in a single place, verses two[/color][/color]
> places).[color=green][color=darkred]
> > > > Note there are ways to mitigate the coupling to ASP.NET if you[/color][/color][/color]
choose[color=blue]
> to[color=green][color=darkred]
> > > put
> > > > the property in the domain class...
> > > >
> > > > Hope this helps
> > > > Jay
> > > >[/color]
> > <<snip>>
> >
> >[/color]
>
>[/color]

re: How do you figure out how much memory a class is using?

Hi Joe,

It was about that saving to disk. I think also that that will be possible,
however that will extend the waiting time in my opinion and than there are
more clients waiting and you again need more memory. Where is than the end
when there are comming more and more to your site.

That was the only reason from my message.

Just a thought about your problem.

Cor

re: How do you figure out how much memory a class is using?

Joe,
It really depends on how your Domain objects are organized.

If a Domain object is strictly used by a single Page, I would put the
property in that page's code behind, if it is used by a group of pages, then
I would add a second layer base class for that group of pages. Note: I would
consider 2 pages a group! ;-) For example PageBase is the base page for all
web forms, while TeamPageBase is the base page for "team" web forms, and
UserPageBase is the base page for "user" web forms. Which means both
TeamPageBase & UserPageBase inherit from PageBase.

Alternatively if there is a root Domain object that all other Domain
objects, my PageBase would offer this root...

As far as configurable, generally I "configure" it when I design the class.
This Domain object will always be X, hence my sample is Session, changing it
to Y, would be a design change, based on performance data collected from
running the app. Design changes would require a recompile of the VS.NET
project & redistribute.

If there was a design requirement for it to be "user admin" configurable,
then I would look at creating a provider of sorts, where the web.config had
an entry for what provider to use, and there would be providers for Session,
Viewstate, Cache, Application, and etc...

The provider would follow the Plug-in pattern, similiar to the provider
pattern in ASP.NET 2.0

http://msdn.microsoft.com/library/de...sp02182004.asp

Note if I supported the provider option, the settings in the web.config
would be in a custom configuration section.

I would not use a select case in this case, as Select cases are not OO...
However that is a different discussion. See
http://www.refactoring.com/catalog/r...ymorphism.html
for a start on that discussion ;-)

Hope this helps
Jay

"Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
news:ucYACrgLEHA.3712@TK2MSFTNGP11.phx.gbl...[color=blue]
> Jay,
> I have a Page base class for my app so what you are saying makes sense.
>
> Since I could have dozens (or hundreds) of Business Objects, do you think
> the idea of using a Property for each one of them makes sense in the Base
> class or should I have a Property on the given page that consumes the BO?
>
> Also, I noted that in the sample Property there was just the use of[/color]
Session.[color=blue]
> Are you saying that you would just edit the Property and change it to
> Viewstate if you wanted to change how it is stored?
> But wouldn't that require you to re-compile and re-distribute the
> application .dll?
>
> I am wondering if it makes sense to be more "configurable" and set flags[/color]
in[color=blue]
> web.config and then use SelectCase in the Property Get/Set to determine[/color]
the[color=blue]
> value of the flag and implement any of these:
> Application, Cache, Session, Viewstate.
>
> Then a client who is low on RAM could switch the flag in web.config from
> UseSession to UseFiles (or somethinng like that - maybe an Enum) and the[/color]
app[color=blue]
> would behave differently without a re-compilation.
>
> What do you think?
> --
> Joe Fallon
>
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:#K0NiSfLEHA.3684@TK2MSFTNGP12.phx.gbl...[color=green]
> > Doh!
> > I should add: All web forms within my web app would inherit from the
> > PageBase class, as I showed for WebForm1.
> >
> > Hope this helps
> > Jay
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:Odkw72eLEHA.2244@tk2msftngp13.phx.gbl...[color=darkred]
> > > Joe,
> > > Basically its an extension of the Encapsulate Downcast refactoring.
> > > http://www.refactoring.com/catalog/e...eDowncast.html
> > >
> > > Rather then have the DirectCast of Session variables scattered[/color][/color]
> throughout[color=green]
> > my[color=darkred]
> > > code, I encapsulate the downcast into a property, normally in a base[/color]
> > class.[color=darkred]
> > >
> > > Normally something like:
> > >
> > > ' in PageBase.vb file
> > > Public Class PageBase
> > > Inherits System.Web.UI.Page
> > >
> > > Public Property ShoppingCart() As ShoppingCartDataSet
> > > Get
> > > Return DirectCast(Session("ShoppingCart"),
> > > ShoppingCartDataSet)
> > > End Get
> > > Set(ByVal value As ShoppingCartDataSet)
> > > Session("ShoppingCart") = value
> > > End Set
> > > End Property
> > >
> > > End Class
> > >
> > >
> > > ' in WebForm1.aspx.vb
> > > Public Class WebForm1
> > > Inherits PageBase
> > >
> > > Private Sub Page_Load(...) Handles MyBase.Load
> > > DataGrid1.DataSource = Mybase.ShoppingCart.Items
> > > DataGrid1.DataBind()
> > > End Sub
> > >
> > > End Class
> > >
> > > ' in WebForm1.aspx
> > > <%@ Page Language="vb" AutoEventWireup="false"[/color]
> > Codebehind="WebForm1.aspx.vb"[color=darkred]
> > > Inherits="SampleWebApp.WebForm1" %>
> > >
> > >
> > > Where ShoppingCartDataSet is a typed dataset that represents the[/color][/color]
> shopping[color=green][color=darkred]
> > > cart.
> > >
> > > Benefits of the above include, but are not limited to:
> > > - Session Variable name is in a single location
> > > - Easy to change from Session to Cache or Disk & back
> > > - Downcast is in a single location
> > > - Enables dynamic creation, the Get could create & initialize the[/color][/color]
> Session[color=green][color=darkred]
> > > variable if it did not already exist
> > > - The code that consumes the Session variable is cleaner (there is no
> > > downcast & checks)
> > >
> > > If your case, the check of the web.config setting would be in a single[/color]
> > spot,[color=darkred]
> > > the property's Get & Set methods.
> > >
> > > Even if the Session variable is used in a single location I would[/color][/color]
> probably[color=green][color=darkred]
> > > apply the same pattern, as invariable the session variable winds up[/color][/color]
> being[color=green][color=darkred]
> > > used in multiple places, its more consistent with other code, and it
> > > promotes "cleaner" code.
> > >
> > > Hope this helps
> > > Jay
> > >
> > > "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> > > news:%23HN%23ngeLEHA.1192@TK2MSFTNGP11.phx.gbl...
> > > > Jay,
> > > > That is very interesting.
> > > > Session, Viewstate, Cache, Application,
> > > >
> > > > Can you elaborate on how you control these with some sample code?
> > > >
> > > > I am sure it is not an "all or nothing" solution. You must be able[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > > control a given variable (like my large collection) using any one of
> > > > Session, Viewstate, Cache, Application. I would like to see how you[/color][/color][/color]
do[color=blue][color=green]
> > it[color=darkred]
> > > so
> > > > I don't go down the wrong path again!
> > > >
> > > > Thanks for another good idea!
> > > >
> > > > --
> > > > Joe Fallon
> > > >
> > > >
> > > >
> > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color]
> > message[color=darkred]
> > > > news:uRivVYeLEHA.2716@tk2msftngp13.phx.gbl...
> > > > > Joe,
> > > > > > So instead of the normal 2 lines of code (1 to put the object[/color][/color][/color]
into[color=blue][color=green][color=darkred]
> > > > Session
> > > > > > and 1 to take it out)
> > > > > > I just wrap them in an If statement and check the flag.
> > > > > I hope you encapsulated your If in a property in a well known[/color][/color][/color]
place.[color=blue][color=green][color=darkred]
> > > > >
> > > > > In fact I normally encapsulate all access to Session, Viewstate,[/color]
> > Cache,[color=darkred]
> > > > > Application, & etc variables in properties in a well known place.[/color][/color]
> This[color=green][color=darkred]
> > > > > allows a "single" point of change if I decide that Cache is better[/color]
> > then[color=darkred]
> > > > > Session for the variable...
> > > > >
> > > > > This well known place could either be a shared property of a[/color][/color][/color]
domain[color=blue][color=green][color=darkred]
> > > class
> > > > > (causes coupling to ASP.NET) or a base Page or Control class in[/color]
> > ASP.NET.[color=darkred]
> > > I
> > > > > normally go for the base Page or Control class, although the[/color][/color][/color]
domain[color=blue][color=green][color=darkred]
> > > class
> > > > > makes its easier (the property is in a single place, verses two[/color]
> > places).[color=darkred]
> > > > > Note there are ways to mitigate the coupling to ASP.NET if you[/color][/color]
> choose[color=green]
> > to[color=darkred]
> > > > put
> > > > > the property in the domain class...
> > > > >
> > > > > Hope this helps
> > > > > Jay
> > > > >
> > > <<snip>>
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

re: How do you figure out how much memory a class is using?

Jay,
Thanks a lot for the pointers.

I added some Properties to my Base page and it works perfectly.
After some playing around I decided to offer the 2 choices (Session of file
serialization) and configured the Property Gets and Sets to check the config
file to see which way to handle it.

I appreciate the help!
--
Joe Fallon




"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:u%23yFbrjLEHA.2012@TK2MSFTNGP11.phx.gbl...[color=blue]
> Joe,
> It really depends on how your Domain objects are organized.
>
> If a Domain object is strictly used by a single Page, I would put the
> property in that page's code behind, if it is used by a group of pages,[/color]
then[color=blue]
> I would add a second layer base class for that group of pages. Note: I[/color]
would[color=blue]
> consider 2 pages a group! ;-) For example PageBase is the base page for[/color]
all[color=blue]
> web forms, while TeamPageBase is the base page for "team" web forms, and
> UserPageBase is the base page for "user" web forms. Which means both
> TeamPageBase & UserPageBase inherit from PageBase.
>
> Alternatively if there is a root Domain object that all other Domain
> objects, my PageBase would offer this root...
>
> As far as configurable, generally I "configure" it when I design the[/color]
class.[color=blue]
> This Domain object will always be X, hence my sample is Session, changing[/color]
it[color=blue]
> to Y, would be a design change, based on performance data collected from
> running the app. Design changes would require a recompile of the VS.NET
> project & redistribute.
>
> If there was a design requirement for it to be "user admin" configurable,
> then I would look at creating a provider of sorts, where the web.config[/color]
had[color=blue]
> an entry for what provider to use, and there would be providers for[/color]
Session,[color=blue]
> Viewstate, Cache, Application, and etc...
>
> The provider would follow the Plug-in pattern, similiar to the provider
> pattern in ASP.NET 2.0
>
>[/color]
http://msdn.microsoft.com/library/de...sp02182004.asp[color=blue]
>
> Note if I supported the provider option, the settings in the web.config
> would be in a custom configuration section.
>
> I would not use a select case in this case, as Select cases are not OO...
> However that is a different discussion. See
> http://www.refactoring.com/catalog/r...ymorphism.html
> for a start on that discussion ;-)
>
> Hope this helps
> Jay
>
> "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> news:ucYACrgLEHA.3712@TK2MSFTNGP11.phx.gbl...[color=green]
> > Jay,
> > I have a Page base class for my app so what you are saying makes sense.
> >
> > Since I could have dozens (or hundreds) of Business Objects, do you[/color][/color]
think[color=blue][color=green]
> > the idea of using a Property for each one of them makes sense in the[/color][/color]
Base[color=blue][color=green]
> > class or should I have a Property on the given page that consumes the[/color][/color]
BO?[color=blue][color=green]
> >
> > Also, I noted that in the sample Property there was just the use of[/color]
> Session.[color=green]
> > Are you saying that you would just edit the Property and change it to
> > Viewstate if you wanted to change how it is stored?
> > But wouldn't that require you to re-compile and re-distribute the
> > application .dll?
> >
> > I am wondering if it makes sense to be more "configurable" and set flags[/color]
> in[color=green]
> > web.config and then use SelectCase in the Property Get/Set to determine[/color]
> the[color=green]
> > value of the flag and implement any of these:
> > Application, Cache, Session, Viewstate.
> >
> > Then a client who is low on RAM could switch the flag in web.config from
> > UseSession to UseFiles (or somethinng like that - maybe an Enum) and the[/color]
> app[color=green]
> > would behave differently without a re-compilation.
> >
> > What do you think?
> > --
> > Joe Fallon
> >
> >
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:#K0NiSfLEHA.3684@TK2MSFTNGP12.phx.gbl...[color=darkred]
> > > Doh!
> > > I should add: All web forms within my web app would inherit from the
> > > PageBase class, as I showed for WebForm1.
> > >
> > > Hope this helps
> > > Jay
> > >
> > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
> message[color=green][color=darkred]
> > > news:Odkw72eLEHA.2244@tk2msftngp13.phx.gbl...
> > > > Joe,
> > > > Basically its an extension of the Encapsulate Downcast refactoring.
> > > > http://www.refactoring.com/catalog/e...eDowncast.html
> > > >
> > > > Rather then have the DirectCast of Session variables scattered[/color]
> > throughout[color=darkred]
> > > my
> > > > code, I encapsulate the downcast into a property, normally in a base
> > > class.
> > > >
> > > > Normally something like:
> > > >
> > > > ' in PageBase.vb file
> > > > Public Class PageBase
> > > > Inherits System.Web.UI.Page
> > > >
> > > > Public Property ShoppingCart() As ShoppingCartDataSet
> > > > Get
> > > > Return DirectCast(Session("ShoppingCart"),
> > > > ShoppingCartDataSet)
> > > > End Get
> > > > Set(ByVal value As ShoppingCartDataSet)
> > > > Session("ShoppingCart") = value
> > > > End Set
> > > > End Property
> > > >
> > > > End Class
> > > >
> > > >
> > > > ' in WebForm1.aspx.vb
> > > > Public Class WebForm1
> > > > Inherits PageBase
> > > >
> > > > Private Sub Page_Load(...) Handles MyBase.Load
> > > > DataGrid1.DataSource = Mybase.ShoppingCart.Items
> > > > DataGrid1.DataBind()
> > > > End Sub
> > > >
> > > > End Class
> > > >
> > > > ' in WebForm1.aspx
> > > > <%@ Page Language="vb" AutoEventWireup="false"
> > > Codebehind="WebForm1.aspx.vb"
> > > > Inherits="SampleWebApp.WebForm1" %>
> > > >
> > > >
> > > > Where ShoppingCartDataSet is a typed dataset that represents the[/color]
> > shopping[color=darkred]
> > > > cart.
> > > >
> > > > Benefits of the above include, but are not limited to:
> > > > - Session Variable name is in a single location
> > > > - Easy to change from Session to Cache or Disk & back
> > > > - Downcast is in a single location
> > > > - Enables dynamic creation, the Get could create & initialize the[/color]
> > Session[color=darkred]
> > > > variable if it did not already exist
> > > > - The code that consumes the Session variable is cleaner (there is[/color][/color][/color]
no[color=blue][color=green][color=darkred]
> > > > downcast & checks)
> > > >
> > > > If your case, the check of the web.config setting would be in a[/color][/color][/color]
single[color=blue][color=green][color=darkred]
> > > spot,
> > > > the property's Get & Set methods.
> > > >
> > > > Even if the Session variable is used in a single location I would[/color]
> > probably[color=darkred]
> > > > apply the same pattern, as invariable the session variable winds up[/color]
> > being[color=darkred]
> > > > used in multiple places, its more consistent with other code, and it
> > > > promotes "cleaner" code.
> > > >
> > > > Hope this helps
> > > > Jay
> > > >
> > > > "Joe Fallon" <jfallon1@nospamtwcny.rr.com> wrote in message
> > > > news:%23HN%23ngeLEHA.1192@TK2MSFTNGP11.phx.gbl...
> > > > > Jay,
> > > > > That is very interesting.
> > > > > Session, Viewstate, Cache, Application,
> > > > >
> > > > > Can you elaborate on how you control these with some sample code?
> > > > >
> > > > > I am sure it is not an "all or nothing" solution. You must be able[/color][/color]
> to[color=green][color=darkred]
> > > > > control a given variable (like my large collection) using any one[/color][/color][/color]
of[color=blue][color=green][color=darkred]
> > > > > Session, Viewstate, Cache, Application. I would like to see how[/color][/color][/color]
you[color=blue]
> do[color=green][color=darkred]
> > > it
> > > > so
> > > > > I don't go down the wrong path again!
> > > > >
> > > > > Thanks for another good idea!
> > > > >
> > > > > --
> > > > > Joe Fallon
> > > > >
> > > > >
> > > > >
> > > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in
> > > message
> > > > > news:uRivVYeLEHA.2716@tk2msftngp13.phx.gbl...
> > > > > > Joe,
> > > > > > > So instead of the normal 2 lines of code (1 to put the object[/color][/color]
> into[color=green][color=darkred]
> > > > > Session
> > > > > > > and 1 to take it out)
> > > > > > > I just wrap them in an If statement and check the flag.
> > > > > > I hope you encapsulated your If in a property in a well known[/color][/color]
> place.[color=green][color=darkred]
> > > > > >
> > > > > > In fact I normally encapsulate all access to Session, Viewstate,
> > > Cache,
> > > > > > Application, & etc variables in properties in a well known[/color][/color][/color]
place.[color=blue][color=green]
> > This[color=darkred]
> > > > > > allows a "single" point of change if I decide that Cache is[/color][/color][/color]
better[color=blue][color=green][color=darkred]
> > > then
> > > > > > Session for the variable...
> > > > > >
> > > > > > This well known place could either be a shared property of a[/color][/color]
> domain[color=green][color=darkred]
> > > > class
> > > > > > (causes coupling to ASP.NET) or a base Page or Control class in
> > > ASP.NET.
> > > > I
> > > > > > normally go for the base Page or Control class, although the[/color][/color]
> domain[color=green][color=darkred]
> > > > class
> > > > > > makes its easier (the property is in a single place, verses two
> > > places).
> > > > > > Note there are ways to mitigate the coupling to ASP.NET if you[/color]
> > choose[color=darkred]
> > > to
> > > > > put
> > > > > > the property in the domain class...
> > > > > >
> > > > > > Hope this helps
> > > > > > Jay
> > > > > >
> > > > <<snip>>
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]