Beginner is foggy on Viewstate and Postback, needs help.

[jsteph]

I'm relatively new to ASP.Net and I'm trying to get my head around the whole ViewState and PostBack concept. So I'm wondering if anyone can help me understand an abstract, high-level view of it all. I've read several recommended links on viewstate and postback, and I think I have a general understanding of what happens, but somehow I keep asking myself "why?".

To give a frame of reference, I'm used to classic asp with ajax. So for example, if I had a data grid to update, it was an html table generated in an asp page and viewd in an iframe. Then in javascript I'd copy the selected row (including a binary timestamp field) and send it via xmlhttprequest to an asp page that performed the update. If the timestamp was unchanged, but the passed-in field values differed from the db values, then the update is performed for those fields and a simple success message and the new binary timestamp is sent back--not an entire re-rendered page, not the entire grid, not evnen the row--because the db now has the same values that are onscreen. I'm not really thinking security here--the environment is internal and, for all intents and purposes, trusted.

So I'm getting pressure to move things to .Net, not just from powers-that-be, but honestly I'm starting to feel like classic asp is being treated like someone using DOS 5.0.

I guess I'm just not seeing the advantage in somehow saving the entire page in some hidden Viewstate field, schlepping that back to the server, and then re-rendering the entire page--whether it's a single record page or an entire grid. In addition--it's unclear to me why a hidden field is needed--if there's a Postback, why wouldn't the page just send the actual values in the field back and whatever needed to be done--ie, the reason the postback was called--could be done and those same values passed back.

Please excuse me if I seem dense on this, it's a new concept and it's hard for me to embrace it when I'm not seeing a real benefit.
Thanks,
--Jim

 

[jbenson001]

If you don't like/understand it then you should look into the MVC way of doing things. Jason, who posts here often, uses that structure, and I'm sure will have alot to say in response to your question.
I also came from a classic ASP background and it did take me some time to understand the concepts. However, you may better suited to use MVC.

 

[jmeckley]

JB, thank you for the introduction

Jim, JB is correct. I wouldn't waist anytime with Webforms. If it didn't immediately click, then you will be fighting the framework every step trying to figure out 1) why and 2) how it works the way it does.

MVC will be more natural for you. there are 3 major MVC frameworks
MS MVC 3
Castle Monorail 2.x
FUBU MVC

I use Monorail, but all 3 are solid. Had FUBU MVC been out prior to my adoption of MVC I would probably have chosen it.

In you scenario I would start with MS MVC. It's endorsed by MS has a solid team of developers and is quickly becoming the defacto MVC framework.

With MVC you have your choice of HTML rendering engine. Each MVC framework has a default engine, but you can swap them out.

MS MVC defaults to WebForms. But not the same webforms you are currently working with. It uses the same syntax markup, but postback and viewstate are not there. all the "advanced" web servcer controls wouldn't be of any use.

Another option is Razor. This is a brand new view engine from MS, which is so much better than Webforms markup.
My preference is Spark. This html engine has the cleanest syntax of all the a rendering templates.

HTH

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[jsteph]

jbenson, jmeckley,
Thank you both. It seems that all I hear about is the .Net way, and it's refreshing to know that there are alternatives that seems to have been well recieved. I'm going to look into those frameworks and see what I find.
Thanks again,
--Jim