OO Help

[Harry Simpson]

I've traditionally used classes just for functions and subs. I was playing around with using a class with lots of properties. But as the page posts back the object has to be reinstaniated and looses the values for the instance because it always creates the object all over again. Putting the instantiation in the Ifnotispostback doesn't help cause the object gets redimmed even before the load each time....here's the code:

Only when I assign values within the click event of the last button does the text show the values...
Dim mPatient As clsPatient

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

If Not IsPostBack Then

mPatient = New clsPatient

End If

End Sub

Public Sub btnAddClass_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnAddClass.Click

'Assign values to the instance

mPatient.FirstName = txtFirstName.Text

mPatient.Phone = txtPhone.Text

End Sub

Private Sub btnViewClass_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnViewClass.Click

lblOutput.Text = "The Patient Name is " & mPatient.FirstName & " the Phone# is " & mPatient.Phone & "."

End Sub

How's this done in ASP.NET using classes with properties....must the class be instantiated and recieve values all within the same sub each time??

TIA

Harry

 

[Wouter van Vugt]

Hi Harry,

the answer to your last question is yes. The system you describe is
basically what ASP.NET does. Each request it recreates the entire page
objects by instantiating your page and beginning a specific cycle:

- Page Init (event)
- On a postback:
load postback data and viewstate
- Page Load (event)
- On a postback:
Fire change events
Fire click events
- Page PreRender (Event)
- Render (method)
- Unload (event)
- Dispose

You basically have to store each object somewhere. You can choose
various solutions:
- Viewstate (useable only between postbacks, use the ViewState
property)
- Session state (the Session property, or use
HttpContext.Current.Session)
- Application state ( the Application property or
HttpContext.Current.Application)
- Cookies
- Querystring variables
- A backend storage system, e.g. a database, XML files, static
objects(not recommended)

Many applications use some layered model to do this all.
Something like:
- A UI layer, recreated each request
- A 'process' layer, stateless, containing static objects which service
database requests
- A dataaccess layer to abstract the database specifics,

You can download my CMS'ish application called SharpCMS, downloadable
from www.dive-in-it.nl. It is a bit of a testbed, so not all code is in
the right place (built on top of the dotNET 2.0 framework). It uses
something like I just described.

There are some rules attached to each stage in the all of this (and I
was somewhat simplified on some areas). Read up on the full story on
MSDN.
http://msdn2.microsoft.com/en-us/library/98wzsc30.aspx

Regards,

Wouter van Vugt
Trainer InfoSupport - www.infosupport.com
www.dive-in-it.nl

 

[Harry Simpson]

Thanks Wouter,

I'd used session objects for properties before.....using class properties u
still must store the class instance in a session object is what your
saying......

Thanks
Harry