What would do you consider to be the best way to handle large amounts of data on the client side? How about from a security standpoint?
I've been looking into the different methods to store and manipulate query results on the client side. The application I've been working on is an intranet site that has rate calculation functions as one of the features.
So far it's been running nicely on the lan but now we are looking to making this available online to provide access to other sites and telecommuting.
As is every single postback results in multiple calls to the database. This is costly in itself and adding more users will just exasperate the problem. The data on the client would need to be encrypted or at the very least obfuscated, and removed at the end of each user session.
Based on what I've learned so far at the very least it will require me to learn javascript, but are there other options out there? Most of my work is in C# and I'm not sure I'll have the time to properly learn a new language.
What do you consider to be the best approach to this problem?
you can serialize your data to JSON format, embed it to a webpage, then after the modifications post it back. javascript is not a hard language, to work with JSON small amount of javascript knowledge would suffice.
I think you can also cache the dataset in the servers memory, then let the users modify that cached memory, after some certain time using tableAdapter update the database. For example if 1000 users pull the same data from the IIS, it is not going to query Sql server, it is going to pull the data from its cache. For updates and deletions you have to handle concurrency conflicts, for caching i have a little article you may like to see: http://www.coderewind.com/?categ&view_article=101
Thanks for the food for thought. The article was a good read too.
I can see both approaches being useful in my situation.
Would you know off hand if the server side cache can be shared between user sessions? Any special considerations required? Aside from the obvious concurrency issues, I'm looking to store read-only data for the time being.
It would be useful to be able to cache a dataset while a given control is in use. Say multiple users working on the same customer at the same time. Free the memory when no one is using it or a timeout.
Looks like I'm finally going to have to get around to learning javascript.
Thanks for the food for thought. The article was a good read too.
I can see both approaches being useful in my situation.Would you know off hand if the server side cache can be shared between user sessions? Any special considerations required? Aside from the obvious concurrency issues, I'm looking to store read-only data for the time being.
It would be useful to be able to cache a dataset while a given control is in use. Say multiple users working on the same customer at the same time. Free the memory when no one is using it or a timeout.
Looks like I'm finally going to have to get around to learning javascript.
If your problem is about not querying the database, you dont have to use javascript. For concurency conflicts you can use Sql server's cache invalidator, which invalidates the server's cache when change occurs in your datatables. So users will always see the new data. And if you have the users do the updates and deletions directly on the Sql server instead of the Dataset object, you wont have any concurrency conflicts at all. So finally, the data that is going to be displayed will be cached in IIS cache using a dataset object, this cache will be invalidated when change occurs in sql server, and all the updates and deletions will be made directly to the database not on the cached version of the dataset object.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.