I'm still a relative noob, however I was surprised at the results of a small test I did.
I want to store a list of string in viewstate. To date when I want to modify the list I retrieved it from viewstate, performed a List.Add and saved it back to viewstate.
However, I then decided to do a simple test, here it is below:
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
List<string> s = new List<string>();
s.Add("abc");
s.Add("def");
ViewState.Add("test", s);
s.Add("one");
s.Add("two");
}
var t = (List<string>)ViewState["test"];
foreach (var str in t)
{
Response.Write(str + "<br>");
}
}
As you can see, I create a list, add it to viewstate, then modify the list. To my suprise the list is modified in viewstate , even after postback.
The question is, is it safe to do this, and if so is it considered bad practice.
Thanks in advance.
ViewState is only serialized to the client page at the time of postback.
Previous to that, it is held in memory and safe for editing.
I often use ViewState as a backer to a property:
public Class1 MyClass1
{
get { return (Class1)ViewState["MyClass1"]; }
set { ViewState["MyClass1"] = value; }
}
In general, I would not consider it bad practice to do so, except for the following:
Storing sensitive data - Since data is serialized to the client, it is susceptible to being changed.
Large amounts of data - Since the data is persisted to the client, it will increase the page load times significantly for large amounts.
The reason you're seeing this is due to the Asp.Net WebForms page life cycle. At the point you're modifying the view state, Asp.Net has not yet rendered the page output as HTML. Since you're adding a reference to a dictionary, and changes you make prior to rending will show up. There are other points in the life cycle where such changes might not show up, although I've not investigated to see if that's the case or not.
I would not consider this good practice however. ViewState is serialized as a hidden form field in your web page, and thus any data in it is part of your page. This can at best just increase the size of the response sent to the client (sometimes significantly, if you store a lot of data there). Since it's a hidden form field, the request back to the server is also larger.
It can also open up security holes. You cannot trust necessarly trust view state, although there are ways you can secure it, but I would say its better not to send any data at all you don't absolutely need to render the page.
As an alternative, you may consider storing state that is specific to the user in Session, although you do need to take some extra effort if you're application will be behind a load balancer in a web farm. Storing the data in session will keep it isolated from other users and won't require exposing the data at all to the client.
Kind of subjective, but I don't see anything wrong with this by practice. This is something that happens all the time within different form controls on the page. The controls will edit viewstate information pertaining to themselves and persist that over postback. The reason the list changes in the viewstate when you modify it after adding it to the viewstate is that it doesn't get immediately serialized. The list is passed by reference to the viewstate collection where it sits until the page serializes the viewstate shortly before completing the request.
Related
On asp.net page, I am using tabs and one of the tab has got user control on it.
On the first tab, data is being displayed from table A and the second tab (which has user control on it) is getting data from table B.
On the user control (second Tab), I need to show the column value of table A. It is just one string value.
I am wondering if there is any best way of displaying the value of a table A column without making a call to database?
The way code has been designed, I can’t access the user control’s textbox from the first tab.
I can only think of using view state or session but don’t know if I should use them instead of making call to DB.
I want value to live for the current page's lifecycle.
If you can save it in viewstate then go for it. But there are plenty of storage options in addition to just viewstate:
querystring (good for Ids, not great for strings)
cookie (pretty straight forward)
local storage (HTML 5 only)
cache (you could still appear to make the call but just have the results cached. you then have to deal with cache expiration as well)
session (as you mentioned, this is basically a per-person cache usage, but is not a bad option)
hidden field (basically what viewstate is)
Even with all of those options, the viewstate is going to be a pretty good one, but it just requires that you post back the viewstate every time you need that value.
How about using js to copy the data contents from tab1? Are you loading the usercontrols in tabs using ajax?
If you have a complex form and need to split into smaller chunks I would use a multiview control with as many views as you need to complete your task. If you design each view with its own controls, validation groups and logics .net will do the rest, you won't have to manually deal with states or saving middle steps
<asp:MultiView ID="MultiView1" runat="server">
<asp:View ID="View1" runat="server">
<asp:TextBox ID="txt1" runat="server" />
<asp:Button ID="Button1" runat="server" Text="Next" OnClick="NextStep_Click" />
</asp:View>
<asp:View ID="View2" runat="server">
<asp:TextBox ID="txt2" runat="server" />
<asp:Button ID="Button2" runat="server" Text="End" OnClick="EndProcess_Click" />
</asp:View>
</asp:MultiView>
<asp:TextBox ID="txt3" runat="server" />
In code behind
protected void NextStep_Click(object sender, EventArgs e)
{
MultiView1.SetActiveView(View2);
txt2.Text = txt1.Text;
}
protected void EndProcess_Click(object sender, EventArgs e)
{
txt3.Text = txt1.Text + " " + txt2.Text;
}
you can go back and forth the times you want and won't have to worry with the values the users entered. Obviously, you have to put buttons to go back and just set the active view you want.
The problem of ouputcaching is avoiding accessing the object, it is cached and it will not be processed at ALL and it is a HTML. for example, what if I want to post back to initialize countries drop down list with specific selection, I don't want to go back and rebuild the whole control and rebind to a collection of countries to just intialize the contol to a certain country.
Output caching will not solve the problem because it caches the HTML, not the object, the object will be null, I can't manipulate it.
Is there away to cache the server object rather than caching its output html?
If u don't think this is possible please reply back, so I know that it is impossible if alot of people say so.
Thanks
It's quite possible - just use the HttpRuntime cache:
HttpRuntime.Cache.Add("myKey", myCountryList);
And then fetch the object back out:
CountryList myCountryList = HttpRuntime.Cache["myKey"] as CountryList;
if(myCountryList == null)
{
//the object isn't in cache
}
This is the most simple usage - the cache is fairly robust and supports some more complex behaviors like invalidation, callbacks, etc. which is all covered in the link above.
We are working on an ASP.NET application. It has 3- 4 forms displaying country list dropdown. Here we would like to avoid binding these dropdowns each time by getting data from database. Instead looking for a better practice of binding it one time, say on application load/some other.
Would you please let me know how we could go head on this? Any reference link or document would be great.
Many Thanks,
Regards,
Nani
Place the drop down in a user control and enable output caching on the user control.
This solution cause the rendered HTML to be cached so the databinding won't need to be called on every page request.
Another possibility would be to use some caching mechanism on your BL logic. For instance in your page/usercontrol you could have (don't take my syntax too strict ;) )
public partial class MyPaged: Page
{
public void PageLoad(..)
{
if(!IsPostBack)
{
dropDownCountries.DataSource = CountryBL.GetCountries();
dropDownCountries.DataBind();
}
...
}
}
and in your business logic class you do some kind of caching where you may have a singleton class that holds the countries and functions as your cache. A pseudocode method could be
public IList<Country> GetCountries
{
//if the cache is empty or it should be refreshed, fills the local
//list of countries, i.e. the cache, with fresh entries from the DB
//there could be some time condition, i.e. refresh every day or so
EnsureCacheValid();
return CachedCountries; //the cache of countries
}
This could be another option with the advantage that your presentation logic doesn't even know about the caching and if you would add a webservice access or so, you would also benefit from the caching. The only thing you have to pay attention at is if there is the possibility that the user can change the countries (which in your example I don't suppose).
Why is "_requestValueCollection" empty on PostBack?
I have a really strange problem with post backs. In some cases on post backs (this.Request.RequestType == "POST") have null "_requestValueCollection" member. And for ASP.NET that means this.IsPostBack == false.
So I have modified the Page_Load in the following way:
protected void Page_Load(object sender, EventArgs e)
{
if (!this.IsPostBack && this.Request.RequestType != "POST")
{
//REGULAR INIT STUFF
}
else
{
//REGULAR SITE POSTBACK STUFF
}
}
What is possible danger of this approach? So far everything is doing OK (and is pretty rich and complicated page).
It isn't clear from your example what you are attempting to do with this code, so this is mostly a short in the dark.
You probably don't need the second part of the if statement. Checking IsPostBack alone should be sufficient.
_requestValueCollection is not a property, it is a field and probably isn't a good place to get at the data submitted by the client. I suggest instead that you consider using the Form property (this.Request.Form) or the Headers property (this.Request.Headers) depending on what you are looking for. Keep in mind that most of the time you can just get form values from the asp.net controls on the form directly.
You may also want to look at the Request.HttpMethod property if you need to determine the exact http method used to invoke the page.
Edit: Adding info about _requestValueCollection
The mechanics behind the _requestValueCollection being loaded are quite complex, but I took a look at the MS source and from what I can determine the page calls on every control on the page that implements the IPostBackDataHandler interface. For each of these it will call the LoadPostData method which adds the data for that control to the collection.
The main things that I can think of off the top of my head that might cause the collection to be null would be:
no server controls on the page implement IPostBackDataHandler
there is no server form, or the contents of the form weren't sent by the client
Alternately, the page may be using query strings to convey the data to the server, and the query string doesn't contain anything
As I said, this is a bit fuzzy. The Page class is very complex internally and so there could be other ways data gets put into that collection too, but this was all I could find on a casual examination.
I need to retrieve a record from a database, display it on a web page (I'm using ASP.NET) but store the ID (primary key) from that record somewhere so I can go back to the database later with that ID (perhaps to do an update).
I know there are probably a few ways to do this, such as storing the ID in ViewState or a hidden field, but what is the best method and what are the reasons I might choose this method over any others?
It depends.
Do you care if anyone sees the record id? If you do then both hidden fields and viewstate are not suitable; you need to store it in session state, or encrypt viewstate.
Do you care if someone submits the form with a bogus id? If you do then you can't use a hidden field (and you need to look at CSRF protection as a bonus)
Do you want it unchangable but don't care about it being open to viewing (with some work)? Use viewstate and set enableViewStateMac="true" on your page (or globally)
Want it hidden and protected but can't use session state? Encrypt your viewstate by setting the following web.config entries
<pages enableViewState="true" enableViewStateMac="true" />
<machineKey ... validation="3DES" />
Do you want the end user to know the ID? For example if the id value is a standard 1,1 seed from the database I could look at the number and see how many customers you have. If you encrypt the value (as the viewstate can) I would find it much harder to decypher the key (but not impossible).
The alternative is to store it in the session, this will put a (very small if its just an integer) performance hit on your application but mean that I as a user never see that primary key. It also exposes the object to other parts of your application, that you may or may not want it to be exposed to (session objects remain until cleared, a set time (like 5 mins) passes or the browser window is closed - whichever happens sooner.
View state values cause extra load on the client after every post back, because the viewstate not only saves objects for the page, but remembers objects if you use the back button. That means after every post back it viewstate gets slightly bigger and harder to use. They will only exist on he page until the browser goes to another page.
Whenever I store an ID in the page like this, I always create a property
public int CustomerID {
get { return ViewState("CustomerID"); }
set { ViewState("CustomerID") = value; }
}
or
Public Property CustomerID() As Integer
Get
Return ViewState("CustomerID")
End Get
Set(ByVal value As Integer)
ViewState("CustomerID") = value
End Set
End Property
That way if you decide to change it from Viewstate to a session variable or a hidden form field, it's just a case of changing it in the property reference, the rest of the page can access the variable using "Page.CustomerID".
ViewState is an option. It is only valid for the page that you are on. It does not carry across requests to other resources like the Session object.
Hidden fields work too, but you are leaking and little bit of information about your application to anyone smart enough to view the source of your page.
You could also store your entire record in ViewState and maybe avoid another round trip to th server.
I personally am very leery about putting anything in the session. Too many times our worker processes have cycled and we lost our session state.
As you described your problem, I would put it in a hidden field or in the viewstate of the page.
Also, when determining where to put data like this, always look at the scope of the data. Is it scoped to a single page, or to the entire session? If the answer is 'session' for us, we put it in a cookie. (Disclaimer: We write intranet apps where we know cookies are enabled.)
If its a simple id will choose to pass it in querystring, that way you do not need to do postbacks and page is more accessible for users and search engines.
Session["MyId"]=myval;
It would be a little safer and essentially offers the same mechanics as putting it in the viewstate
I tend to stick things like that in hidden fields just do a little
<asp:label runat=server id=lblThingID visible=false />