In my asp.net page, I am using ajax, and I want to know how to keep the variable data when doing an ajax call. Basically on page load, I download a lot of information from a database and display it on the page. Then during an ajax call, I want to use the data stored in the variable, but the problem is, during the ajax call, that data goes away, and I have to re download the data again.
Is there a way to keep it during the ajax call?
In ASP.net you have to many ways to do this, Session["YourNameHere"] you have the vale until the sesion is closed or ViewState["YourNameHere"] you have the value in the page until It is closed.
Some links Using ViewState or
Using SesionState
I hope this help.
EDIT
Using the Viewstate.
First put serializable in you class.
[Serializable]
public class Fruits
{
public string Apple { get; set; }}
Save The value:
Fruits Fruit = YourMethod(); //Yor method that retrive the data from DataBase*
ViewState["Fruit"] = Fruit;
when you'll use the Viewstate:
Fruits Fruit = ViewState["Fruit"]
I want to use the data stored in the variable, but the problem is, during the ajax call, that data goes away, and I have to re download the data again.
This isn't a problem, it's the nature of http and stateless environments.
Depending on the type of data retrieved you there are some mechanisms to cache the values:
application state, session, cache, cookie, static dictionary. It really depends on the context of the data, the usage scenario, the hardware etc.
Your best approach is to avoid caching the object until you know that this is the bottleneck in the system, or for this particular feature.
Related
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.
Say I have a page in my web application that lets a user update their contact information. Pretend in order to retrieve or save this information I have the following class:
public class User
{
DataAccesClass dataAccesClass = new DataAccesClass()
public string UserName {get;set;}
public string Address {get;set;}
public string EmailAddress {get;set;}
public User(){}
public static User GetUser(int userID)
{
User user = dataAccesClass.GetUser(userID); //
return user;
}
public void Save()
{
dataAccesClass.SaveUser(this);
}
}
Say that on my Page_Load event I create a new instance of my User class (wrapped in a !isPostBack). I then use it's public properties to populate text fields on said page in my web application. Now the question is... When the page is posted back, what is the correct way to rebuild this class to then save the updated information? Because the class was created on Page_Load !isPostBack event it is not available. What is the correct way to handle this? Should I store it in a Session? ViewState? Should I simply rebuild it every post back? The User class in this example is small so that might influence the correct way to do it but I'd like to be able to take the same approach for much larger and more complex classes. Also, would this class be considered an acceptable business object?
what is the correct way to rebuild this class to then save the updated information?
I would say the best practice would be do not rebuild the class on every postback. You should build the data on the first request, set values on controls, then let the viewstate on those controls persist the data.
If there is a potential for the data to need to be updated, tie re-generation of the object to an event indicating there is actual need to update.
Should I store it in a Session? ViewState? Should I simply rebuild it every post back?
Selecting whether to store the value in session or re-pull from the data layer should be based on the memory footprint of the object, the scalability requirements of the application, the costliness of the database operation, and the likelihood that the object will need to be accessed on any particular request. So I believe that is highly situational.
Also, would this class be considered an acceptable business object?
I don't have a lot of experience with BLL's but it looks like you're on the right track.
Unless profiling indicates otherwise, it's okay to just reconstruct the object with every request. You can also implement some kind of caching in your data access code. Your class is an acceptable business object.
Given that User object might have info you wouldn't want to expose through ViewState, it can be stored in Session.
This is the "standard" way of doing this in ASP.NET.
In the case of your example, reconstructing the object looks fine as it is small. But if you have a small object you inevitably store for a while, I would use session. If the object is large, I would directly use database or session with database connection.
Depending how complex you are thinking of getting a JavaScript framework called knockout.js might be a good fit. You could create a json object to bind to a jQuery template that would build the HTML depending on the object, it handles complex objects very well.
I have an ASP.NET c# project.
I have to pass a list of values (id numbers such as "23,4455,21,2,765,...) from one form to another. Since QueryString is not possible because the list could be long, which is the best way to do it?
Thanks in advance.
Thanks for all your answers, you are helping a lot !!!
I decided to do this:
On the first form:
List lRecipients = new List();
.....
Session["Recipients"] = lRecipients;
On the final form:
List lRecipients = (List)Session["Recipients"];
Session.Remove("Recipients");
You could use Session collection.
In the first page, use:
List<int> listOfInts = new List<int>();
...
Session["someKey"] = listOfInts
And in the second page, retrieve it like this:
List<int> listOfInts = Session["someKey"] as List<int>;
If your using asp.net webforms you can put it into a session variable to pass stuff from page to page. You've got to be concise of the potential performance issues of putting lots of stuff into session mind.
Session["ListOfStff"] = "15,25,44.etc";
There are any number of ways to pass this data. Which you choose will depend on your environment.
Session state is useful, but is constrained by the number of concurrent users on the system and the amount of available memory on the server. Consider this when deciding whether or not to use Session state. If you do choose session state for this operation, be sure to remove the data when you're done processing the request.
You could use a hidden input field, with runat="server" applied to it. This will make its data available server-side, and it will only last for the duration of the request. The pros of this technique are that it's accessible to both the server code and the client-side JavaScript. However, it also means that the size of your request is increased, and it may take more work to get the data where you want it (and back out).
Depending on how much data's involved, you could implement a web service to serialize the data to a temporary storage medium (say, a database table), and get back a "request handle." Then, you could pass the request handle on the query string to the next form and it could use the "handle" to fetch the data from your medium.
There are all kinds of different ways to deal with this scenario, but the best choice will depend on your environment, time to develop, and costs.
For Asp.NET MVC you can use ViewData.
ViewData["ID"] = "";
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).
I am a VB.net winforms programmer attempting to build an ASP.Net app. I use data classes(objects) through reflection in most of my vb projects and was trying to adapt it to ASP.net using the VB code behind. I have a webpage that serves as an add/edit page for contact info. I instatiate my class which grabs the contact data from the data base then I have a process that loops through the controls on the form and matches up with a property in the data class. I can display data no problem. When I edit data and click the submit button my code calls a then loops through the controls on the form again and matches the control to the property of the data class to update the property of the class. However, my data class is no longer valid. I know web programming is different then winforms but I can't seem to get over the hump on this one. Is this the wrong way to go about this? Is my data class only available on the server side? Do I just reinstantiate the initial class and then loop through the propeties and change what the user changed and then call the update method (see redundant)? How can I get data class into a session object (I made an attempt in the past but was under tight deadlines and had to abandon it, maybe I need to revisit it?)?
Thanks
If you decide to keep some of your data in Session, you owe it to yourself to look at this post. Your code will be much cleaner and easier to maintain.
Yes, you need to reload the data class from the database as one option, or use an alternative approach. The reason is web is stateless, so all local variables are destroyed then the server side page unload process occurs. This means that in between requests, you need something to store your data.
You can read/write an object via the Session colleciton, as so:
Session["A"] = myobj;
myobj = (ObjType)Session["A"];
And so session stores an object for a specific user. Alternatively, cache stores application level data, so one instance of an object is available to all users (where session is unique to each user). You can make cache unique to a user by appending a user ID to the cache string.
var o = Cache.Get("A");
if (o != null) { .. }
Cache.Add("A", o, ...);
And so these mechanisms help you temporarily retain data.
You need to save your data class somewhere, usually in a session variable, otherwise it goes away as soon as the page gets sent back the user. Or else you need to recreate the data class again upon posting.