asp.net - Using a class in PostBack -

i totally new classes , oop, please bear me.

i creating large scale web app i'm trying keep tidy creating own classes.

for instance have public class product has several properties. 1 way using on page load product id assigned id property in turn gets details product , assigns various data other properties. within code can used example product.price or product.description , appropriate values. has worked fine, found because class initiated on page load getting data db each time page refreshed. stopped using if not ispostback initiate class. meant data pulled in on initial page load. far good.

i needed compare value in textbox property of product. have textchanged event with

if textbox1.text <> product.description then....

but here wavy line under product.description , vs2010 saying object not defined. dim'd in page.load moved dim statement outside page class accessible events on page.

the dim statement dim product new product

in not ispostback chunk of code have example product.id = 1 product properties product 1

the wavy line has gone when run page works fine on page load. data displayed product class working fine. make change in textbox1 , event triggers product.description nothing. got reinitalised.

how stop happening...

your "product" not persisted between postbacks.

only control objects in aspx page persisted/restored automatically.

to remedy there multiple approaches.

if product loaded via setting "product.id=1" woudl have hiddenfield receives value of product.id during prerender event (to save in page) , in init event restore "product.id=hiddenfield.value" when postback reload object.

edit

thanks picking answer. i'll elaborate little on various ways deal , why suggested answer.

store key in hiddenfield reload db:

pros: product fresh/correct/current values. corresponding database. databases efficient return record based on primary key. little data sent , posted client browser. low complexity. each page opened client safely isolated.

cons: multiple database transactions. if db strained or extremely massive may need consider smallest efficiency gain, not common or on primary key based record

session state (store entire object):

pros: lowest time "load" object since it's available in memory once loaded. less db transactions. no data piggy backed client , again.

cons: object can become "out-of-date" if altered in db. users open multiple pages of application can end getting wrong object if both require different "product", instead totally safe need more complex structure in place store more 1 product or store them based on kind of key (such product id). server memory used, if serving thousands of users or product data large can become issue, if in many pages many objects.

serialization (store entire object in page in field, similar event state):

pros: once loaded, database accessed once specific product, product held, in it's entirety inside page, recreated server data in field or via viewstate. each page opened client safely isolated. easy implement storing in viewstate of page.

cons: object can become "out-of-date" if altered in db. allot more data added page responce , users next page request. more complex implement because object needs designed serialized correctly. complex objects require allot of manual code serialized successfully.

again, there many other ways deal this, such storing items in synclocked dictionary style object global application, considerablby more , more complex go.