Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] - نسخه متنی

Jeffrey Putz

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید






Using Viewstate


Viewstate is of course the "bucket" that saves the state of all of the controls on the page so that the server can determine what the form looked like before the postback. You might recall from Chapter 7, "The ASP.NET Event Model," that it's transmitted as part of the page in a hidden HTML input field, and it can get quite large.

The size of the encoded viewstate is significantly better in ASP.NET v2.0, but it's still a good idea to think carefully about how it's used. After all, that data has to be sent to the browser and back on every request to the server. Not only does that consume bandwidth and the perceived time it takes for the page to load, but it also means that the server has to do more work encoding and decoding it.

For that reason, all good control authors think hard about how and when they'll save data in the ViewState object. If the control you're developing doesn't need to retain data on postback, you don't need to keep it in viewstate. For example, if you have a control that displays data from Cache, you don't need to save it in viewstate because, on postback, the control can read it from Cache again. There's no reason to encode it, send it to the client, send it back to the server, and then decode it!


/ 146