I am debugging an application that uses an XML file to store data as key/value pairs.
Every pageload the XML file is parsed to populate a Dictionary collection with these key/value pairs. The Dictionary is then used to look up values based on their keys.
Is this method of loading data from an XML file on every page load a good practice?
Here are some thoughts:
Should the XML data be stored in a database table instead?
Should I work with a collection or hit the database for every lookup request?
Could the collection be loaded on application start and set as a global/application property?
What do you guys think?
I would suggest loading the results of the XML Parsing into the ASP.NET Cache:
Dictionary<string, object> values = new Dictionary<string, object>();
if(Cache["ConfigDictionary"] != null)
{
values = (Dictionary<string, object>)Cache["ConfigDictionary"];
}
else
{
// Load data into the dictionary here
// This dependency will ensure that you don't keep stale data in the cache
CacheDependency dependency =
new CacheDependency(Server.MapPath("yourFileHere.xml"));
// Inser the Dictionary into the cache
Cache.Insert("ConfigDictionary", values, dependency);
}
I agree with #Justin, keeping the collection into cache is nice.
Also, the question about storing data in a database, depends mostly on what content the app is loading. If there is config settings, or another data that has low probability to change, I think is more efficient keeping it in a XML file. Why?
Easier to maintain;
You dont need to care about connections, queries, parameters;
Easier to view data content;
Non database-skilled people (support for app), can change settings.
I would store it in the database instead of XML file. It is easier to query (if you have to run some reports for example) and also backup is sort of more controllable.
Of course, I assume you are using database for your web application in general.
You may try to use Viewstate to decrease number of database runs if your are in the context of the same web page.
Related
I need to share data (string, list, array) between two different aspx pages of the same application. What is the best way to do it if I do not want to use cookies and do not want for data to be visible in url.
a) Form post method
b) Session (cookies?)
c) Sql
d) Server.Transfer
Thanks
In-memory Session will be the simplest and quickest (development-wise) to store data between pages without their contents being visible in the query string (URL), like this:
To store a List<string> in Session, do this:
var listOfStrings = new List<string>();
listOfStrings.Add("1");
listOfStrings.Add("2");
listOfStrings.Add("3");
Session["ListOfStrings"] = listOfStrings;
To retrieve the List<string> from Session, do this:
// Check to see if item in Session is actually there or not
if(Session["ListOfStrings"] != null)
{
// Cast the item in Session to a List<T>, because everything in Session is an object
var myListOfStringsRetrieved = Session["ListOfStrings"] as List<string>;
}
Note: I am assuming you use C#, but this can easily be translated to VB.NET.
Some more details might be helpful. What type of information do you want to share? If it is something that needs to be saved, then perhaps it makes most sense to save the data in your database (or local storage, or what ever you are using) from one page and retrieve it in the other. If it's just temporary data, it probably makes more sense to post the data through a form, or use a session variable. The problem with the session variable is that you might time-out your session. A session variable wouldn't be my first choice.
In my AppStart.cshtml I fetch some data from the database, do calculations, serialize/deserialize json strings and such, etc, and I store the result in a couple AppState-variables by doing something like the following:(C#)
AppState["myVar1"]="aString";
AppState["myVar2"]=anArray;
These variables are accessed frequently and are a bit heavy to define so I thought something like this would make sense rather than creating the data from scratch every time it's needed. Even if the optimization isn't needed it still makes sense to me since it also increases readability and definitely maintainability by not having the same code in a bunch of places where that data is needed.
Likewise, I do similar actions on a per-user basis by putting data in Session whenver a user logs in, e.g.
Session["userVar1"]="myString";
Session["userVar2"]=myAray;
However, I've just read that we should never rely on that the data stored in these still exist when we want to read them because they're stored in the server-memory which might have been cleared.
Is this true?
So when we want to access one of these we should first check whether it's null or not? And if we're lucky it's not null and we can use it straight away, otherwise we set it again.
Is this how data stored in AppState and Session are supposed to be used? And if so, what would be a good way of re-setting them if they're null? I suppose doing something like creating a function which sets them if they're null?
In your case it sounds like it's fine if the data is occasionally cleared by the server (re-starting the app process from IIS, for example) because what you've described is just a caching scenario. Cache data is inherently transient. If it's there, use it. If it's not there, re-fetch it (and populate the cache again with the result).
What I would suggest is abstracting your cache mechanism (app state and session state) from the structure of the cache itself. And within this structure you can check if the data is cached and, if not, re-cache it. Consider an object like this:
public class CacheManager
{
public static string MyString
{
get
{
if (string.IsNullOrWhiteSpace(AppState["myVar1"]))
{
// Fetch the value to be cached and set it in AppState["myVar1"]
}
return AppState["myVar1"];
}
}
}
Now anywhere in your application you can get the value by calling:
CacheManager.MyString
The rest of the application doesn't know or care if it's from app state, or session state, or a database, or a file, or any other transient location for cached data. That's entirely handled by the cache manager object. So if you ever want to change where certain values are located, you change them in that one place. Or if, for testing purposes, you want to remove the cache entirely and always get the data live, you'd just swap out the cache manager implementation with one that always returns re-fetched data. The rest of the application is blissfully unaware of the implementation.
we have an architectual problem with our data grid. The grid supports searching, paging and sorting using a linq2entity query, that contains all of the above parameters.
At some pages, the grid should not display the content from the database (e.g. column 'name'), but the translated ressource, loaded by the Resource Provider.
Our Resource Provider gets the translations from the database and caches them to the application cache to avoid unneccessary trips to the database.
At this point, we have the following possibilities:
No searching, sorting and paging on the databse, so loading all rows, then load the translations from the Resource Provider, then do the searching, sorting and paging at the application.
Bad performance, because the database is very big
Searching, sorting and paging on the database, then load the ressources for the results.The Displayed Values will not match to the search and sort configuration
Get the Resources directly from the database, within the linq query.
The Ressource Provider Caching cannot be used. The Join with the Resource Provider Texts will be very bad and slow
Every possibility is very bad, but I can't think of another solution. Any good suggestions? How are these problems solved in other software?
You can do it by bring the associated filtered records from the database and keep it in ViewState.
How can you improve the Performance?
You can make use of JSON / Page Methods for Database Callings. I will explain it to you with the help
of an example.
Click here to check the code for GridView Bindings using JSON
Mark Up With JSON
I am calling the Code Behind methof from Client side
Code Behind
Output
Click here to check the output in case of Update Panels
Is application is holding too much memory then you need a Doctor like Red Gate Ants Memory Profiler. Click here to see more details about it
Make sure to use the Using Statements to avoid Memory Out of Exceptions
using (SqlConnection connection = new SqlConnection())
{
connection.Open();
//Also for SqlCommand... Sample code...
using (SqlCommand cmd = new SqlCommand())
{
}
using (SqlTransaction transaction = connection.BeginTransaction())
{
transaction.Commit();
}
}
Are you aware about the Teleric Grid? It loads all the records first from the database and keeps in Cache. In order to go for this you must use Paging and Disposing the objects is mandatory. Teleric Grid shows these records in Paging. Thus you can avoid the rendering issue to get rid of displaying all records in once.
i don't understand your question properly but if you want to all operations on translated resource you have to store translated resource in database then get them in to session object and apply filter on it if it is either in form of table or list then give source to grid which has to configured as work with translated resource which is filtered from session object.
I need to implement caching in Asp.net web application
My need to store data with different ID's.
So which method is better ?
Use a dictionary variable. Insert the data (key as ID and data as value).
Dim mDict As New Dictionary(Of String, String)
mDict .Add(bID, uwtTree.WriteXmlString(True, True))
Cache.Insert("mTree", mDict)
Add it to a cache variable.
Access the cache variable
If Not Cache("mTree") is Nothing Then
'cast to dictionary and check ID exists , if exsitis get the data
End iF
Use cache variable for different IDs
Cache.Insert(ID,data)
' each insertion for each ID
If Not Cache(ID) is Nothing Then
' get the data. '
End IF
Which method is the best way ? Or is there any other method exists ?
I am using .Net 3.5 /IIS 7 (VB.Net). Thanks in advance
Way to Improve Performance and Memory Optimization
Without context it's not possible to say which is "better".
But if you put a dictionary in the cache (option 1), better make sure it's a thread-safe dictionary (such as the .NET 4 ConcurrentDictionary).
The most obvious difference between the two approaches is that with option 1, cache item expiry will result in the dictionary with all items being removed at once. With option 2, individual items will expire independently.
In response to the comment:
i am having xml data and i will store in cache (data caching) as string. Is there any difference if i store it as XmlObject ?
The main differences I see are:
String is immutable, so you won't need to worry about thread-safety when accessing it. XML objects are not immutable - so you need to make sure you don't modify the object retrieved from the cache (or use locks to make sure any such modification is thread-safe).
If you store a string, you will presumably parse it into an XML object each time you retrieve it from the cache, which will result in a potential performance penalty.
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"] = "";