custom base classes

[matt.delvecchio]

hello,

i understand the usefulness of having custom base classes when it
pertains to common methods or custom handling of events (say,
overriding all pages OnError and sending out an email of the
exception).

my question perstains to custom properties of a base class. say i write
a base class, and add two new properties to it (example only, not my
actual properties):

- CustomerID
- CustomerName

....would this make sense, if i wanted to be able to use those props
thru out the app ("this.CustomerID"), sorta like using Session
variables? or would it make more sense to just stick w/ Session?

i ask because i tried a test -- created those two new props in my base
class, and then in a page's OnLoad "if (!IsPostBack)" i assigned values
to them. however, on subsequent button events, the props were empty
because they were not assigned to via the OnLoad. hmm. i was hoping
they would retain state.

do i have the wrong idea about using custom props like this? or should
i just stick to using the Session? OR, would it be best to use the
Session only in OnInit, and assign it to these custom props?

just trying to figure the best practice.
thanks!
matt

[Chris Fulstow]

Hi Matt,

Each time a page request is made the ASP.NET Page object is recreated,
so any instance values that were set in the previous request will be
lost. It's possible to get around this by using static class
properties, however these will be lost when the application domain is
recycled, which happen by default every 29 hours, and whenever you
modify web.config. This approach is not considered best practice for
maintaining state across page requests.

Better approaches would be to use the Session object, cookies or the
viewstate, depending on your requirements. For maintaining
application-wide data, consider using a database or the Cache object
(in preference of the Application object). If you want to persist
state data for individual users, take a look at using ASP.NET 2.0
profiles.

Hope that helps,

Chris

[matt.delvecchio]

thanks, chris.

i do wish to persist state data for individual users, however 2.0 is
not an option at this time.

im thinking..what about -- adding user properties to the base class,
and then set/get them via Session? this could be useful because if we
choose to move away from session to cookies, or viewstate, etc, we
could update it in one place, our base class population.. the consuming
applications would never see the change, since they still access
everything view "this.CurrentAssetID" (etc)... is this done?
thanks!
matt

[Chris Fulstow]

Hi Matt,

That would certainly be an option and you could abstract the underlying
state technology in your getter and setter methods.

However, I think a better design would be to create a new "User" or
"Member" class to encapsulate all the data and behaviour associated
with a user. You could then use this to encapsulate your state logic.
This might be a more flexible approach and you could use your User
object from anywhere, including other business objects, without having
to worry about the lifetime or state of your Page object.

Good luck,

Chris

[matt.delvecchio]

chris,

yes, for "User" type information, i think you are correct, that would
be a better approach.

my actual scenario is not for user-info, i just used it for an example
(poor choice). in this actual case, im concerned w/ application data --
which "asset group" the user is manipulating data for (via the app). i
thought it might make sense to this AssetID and AssetName to be stored
in the page base since it pertains to the app itself and not the user.
matt