By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,148 Members | 774 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,148 IT Pros & Developers. It's quick & easy.

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

P: n/a
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


Nov 20 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
* "Joe Fallon" <jf******@nospamtwcny.rr.com> scripsit:
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?


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/>
Nov 20 '05 #2

P: n/a
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]" <hi***************@gmx.at> wrote in message
news:c6************@ID-208219.news.uni-berlin.de...
* "Joe Fallon" <jf******@nospamtwcny.rr.com> scripsit:
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?
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/U...px?SampleGuid=
3254325d-a4aa-4bb3-aa86-c72d5104ec74>
--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 20 '05 #3

P: n/a
Joe,
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. Look at what is actually serialized, there is extra overhead in binary
serialization, as it stores Type & property names in the stream.
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. 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" <jf******@nospamtwcny.rr.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... 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]" <hi***************@gmx.at> wrote in message
news:c6************@ID-208219.news.uni-berlin.de...
* "Joe Fallon" <jf******@nospamtwcny.rr.com> scripsit:
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?
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/U...px?SampleGuid= 3254325d-a4aa-4bb3-aa86-c72d5104ec74>

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


Nov 20 '05 #4

P: n/a
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" <jf******@nospamtwcny.rr.com> wrote in message
news:OF**************@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 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

Nov 20 '05 #5

P: n/a
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]" <Ja************@msn.com> wrote in message
news:uX**************@tk2msftngp13.phx.gbl...
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" <jf******@nospamtwcny.rr.com> wrote in message
news:OF**************@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 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


Nov 20 '05 #6

P: n/a
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, 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" <jf******@nospamtwcny.rr.com> wrote in message
news:uU*************@TK2MSFTNGP11.phx.gbl... 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]" <Ja************@msn.com> wrote in message
news:uX**************@tk2msftngp13.phx.gbl...
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" <jf******@nospamtwcny.rr.com> wrote in message
news:OF**************@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

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



Nov 20 '05 #7

P: n/a
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]" <Ja************@msn.com> wrote in message
news:uR**************@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, 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" <jf******@nospamtwcny.rr.com> wrote in message
news:uU*************@TK2MSFTNGP11.phx.gbl...
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]" <Ja************@msn.com> wrote in message news:uX**************@tk2msftngp13.phx.gbl...
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" <jf******@nospamtwcny.rr.com> wrote in message
news:OF**************@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

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
>
>
>
>



Nov 20 '05 #8

P: n/a
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" <jf******@nospamtwcny.rr.com> wrote in message
news:%2******************@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 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]" <Ja************@msn.com> wrote in message
news:uR**************@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, 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

<<snip>>
Nov 20 '05 #9

P: n/a
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]" <Ja************@msn.com> wrote in message
news:Od**************@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 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" <jf******@nospamtwcny.rr.com> wrote in message
news:%2******************@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 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]" <Ja************@msn.com> wrote in message news:uR**************@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, 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

<<snip>>

Nov 20 '05 #10

P: n/a
Hi Joe,

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

Just my thought?

Cor
Nov 20 '05 #11

P: n/a
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" <no**********@planet.nl> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...
Hi Joe,

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

Just my thought?

Cor

Nov 20 '05 #12

P: n/a
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]" <Ja************@msn.com> wrote in message
news:#K**************@TK2MSFTNGP12.phx.gbl...
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]" <Ja************@msn.com> wrote in message
news:Od**************@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 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" <jf******@nospamtwcny.rr.com> wrote in message
news:%2******************@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 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]" <Ja************@msn.com> wrote in

message news:uR**************@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, 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
>

<<snip>>


Nov 20 '05 #13

P: n/a
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
Nov 20 '05 #14

P: n/a
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" <jf******@nospamtwcny.rr.com> wrote in message
news:uc**************@TK2MSFTNGP11.phx.gbl...
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]" <Ja************@msn.com> wrote in message
news:#K**************@TK2MSFTNGP12.phx.gbl...
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]" <Ja************@msn.com> wrote in message
news:Od**************@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 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" <jf******@nospamtwcny.rr.com> wrote in message
news:%2******************@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 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]" <Ja************@msn.com> wrote in

message
> news:uR**************@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,

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
> >
<<snip>>



Nov 20 '05 #15

P: n/a
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]" <Ja************@msn.com> wrote in message
news:u%****************@TK2MSFTNGP11.phx.gbl...
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" <jf******@nospamtwcny.rr.com> wrote in message
news:uc**************@TK2MSFTNGP11.phx.gbl...
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]" <Ja************@msn.com> wrote in message news:#K**************@TK2MSFTNGP12.phx.gbl...
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]" <Ja************@msn.com> wrote in message news:Od**************@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

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" <jf******@nospamtwcny.rr.com> wrote in message
> news:%2******************@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 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]" <Ja************@msn.com> wrote in
message
> > news:uR**************@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,
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
> > >
> <<snip>>
>
>



Nov 20 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.