OO Help

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 ba
ck the object has to be reinstaniated and looses the values for the instance
because it always creates the object all over again. Putting the instantia
tion 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.Event
Args) 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 Syste
m.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 Sys
tem.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 b
e instantiated and recieve values all within the same sub each time'
TIA
HarryHi 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
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
"Wouter van Vugt" <wouterv@.infosupport.com> wrote in message
news:1132781083.362591.310460@.g43g2000cwa.googlegroups.com...
> 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
>