I've been everywhere trying to find an answer to this so hopefully someone can help.
A little bit of background: I'm getting my feet wet with SignalR and attempting to expand on the Chat Room Example. My idea is basically to have a list of users who have entered the room. I am attempting to do this by storing a list of usernames in a "users" cache key and maintaining and distributing this list when users login/logout. I want to access this list from within my hub's code when requested by the client.
When I use Application I get the desired results but it is my understanding that HttpContext.Current.Application is not the best way to go as it is only there for compatibility with classic asp. I see a lot of recommendations for HttpContext.Current.ApplicationInstance, however, whenever I access this I get a NullPointerException on ApplicationInstance. What is the best way to manipulate some cache keys (or an equivalent) for what I am trying to accomplish?
I wouldn't recommend using Application for this at all. If you simply want to cache and keep it up to date based on events such as login/logout, use a static member on your Hub class or object cache (e.g. http://msdn.microsoft.com/en-us/library/dd997357.aspx)
Use a database, cache or a static variable to store your state. Avoid using HttpContext.Current inside of SignalR.
Related
I’m kind of new to APIs and currently working on a project using the Spoonacular API. Im trying to build a meal planner website. At the moment, I’m working on the “Add To Meal Plan” feature which is a post method. To get the information for the post method, I think have to use a get method to retrieve recipe information from the API using a Recipe ID. I’m using TempData to store the information I get back from the get method so I can use it in my post method. Is this the most efficient way to be doing this? Or is it better to have my get and post requests be in the same method so I don’t have to store anything?
Currently, I’m using TempData to store the recipe information. It works but just not sure if this is the most efficient way to do this. I’m storing an object that I’ve serialized.
Using TempData is an acceptable approach for storing temporary data that needs to be passed from one request to another. It's part of the ASP.NET Core framework and provides a simple way to store values between multiple requests.
However, depending on your specific use case, there might be other ways to store this information that are more efficient. For example, if you want to store the recipe information for multiple users and persist it between sessions, you could consider using a database or a caching solution.
If the information you're storing is specific to a single user session, then TempData might be the best choice as it's relatively lightweight and easy to use.
In terms of combining the get and post requests into a single method, it's not necessary to do so. However, it might be more efficient in terms of network requests and server load if you can reduce the number of requests that need to be made to retrieve the required information.
Tell me if this helps :)
Some background - I am working in a project which requires a kind of headshake authentication. The external service will send a request with a Token, and I will answer with Validator. Then it will send a second request containing the same Token and the data I should store in my database. The token is also used to get a couple extra fields that are required to insert the data in the database. Due to several project constraints and requirements, this "api" is implemented in Serverless (Azure Functions).
Since there are only 100 and something token-validator pairs that are not often updated (I will update manually every month or so), I have decided about not querying the database every time I get an incoming request. Normally I would simply use caching in C#, but since I am working with Functions, the code will be executed in multiple changing processes, which means no shared cache. I also think that using a cache service, such as Redis or Azure Cache would be an overkill.
My current solution - Currently, I am storing the data in a Hashtable that maps a Token to a ValidatorModel object that contains the validator and the extra fields I require. It works pretty well, but since it is a big C# object, it is a pain to update, the IDE lags when I open it, etc. I also don't know if it is a good idea to have it hardcoded in C# like that.
What I have been thinking about - I was thinking about storing a binary protobuf file that contained my Hashmap object. I am unsure if this would work or perform well.
My question - What is the best way do store such data and access it in a performatic way?
I'm trying to use a embedded RavenDB database for a small desktop application written in C# and WPF (using MVVM). Right now I'm asking myself how to handle the sessions the right way. I'm loading some items at the start of the application which may get updated at some time.
What's the best way to handle that?
The solutions I've tought of or read so far are:
use a single session for the whole lifespan of the application - I haven't read about that one, so I don't think it should be a preferred solution
open a session after an object has been changed, load the object again from the server, use a library like ValueInjector to overwrite all values from the local object and save those changes - seems more like a hack fix
Save the etag for each object and use it with the store method to replace the complete object on the database - doesn't seem like a good solution either
So neither of these possibilities seem very good and unfortunately 90% of all samples seem to be for MVC controllers only.
Is there any way to reattach an object from an old, closed session? Or is there any other recommended way to achieve what I want?
This article talks about NHibernate, but pretty much all of it applies to RavenDB session management as well.
http://msdn.microsoft.com/en-us/magazine/ee819139.aspx
I'm working with ASP.NET and I want to load once a big object (specific by user) in my controller and then use it in my view.
I though about a static property but I find some problems with it.
See : Is it a bad idea to use a large static variable?
I'm not familiar with this language and I have no idea how to properly share the same object between the different methods for each user. Could you tell me how to do that ? Do you know if singleton could be a solution ?
A singleton won't help you here if this big object is going to be different for every user.
Without knowing all the details, I'd say perhaps your best option is to store it in the Session object,
HttpContext.Current.Session["bigObject"] = bigObject;
Depending on the size & traffic, this can have performance problems, so I'd suggest you read up on the pros and cons of using Session
If you want to get to use something for the next simultaneous request, then use TempData - which is a bucket where you can hold data that is only needed for the following request. That is, anything you put into TempData is discarded after the next request completes.
If you want to persist the information specific to user, then go for Session. With session, you will have timeout, so that after certain amount of time the data stored in session will be lost. You can configure this value to much more bigger value. Apart from that when you go for Webfarm of servers, then maintaining session will be a problem, probably you might need to go for managing session in SQL Server or in some other store.
Alternatively you can Use Runtime Cache object in ASP.Net MVC to keep all the common data. Cached data can be accessed fast and we have other benefits like expiring cache etc. You can share this Cache object across users, or you can maintain different cache objects for different users, that is purely dependent on your logic. In case of webfarms, yo u have distributed cache servers like redis, Azure Cache service etc., which you can use them.
I am doing my first ASP.NET MVC project. (In fact, for the record, this is my first production website of any kind).
This is a mobile web page targeting HTML 5.
This page looks up some "expensive" information. First it uses the html 5 geocoding feature to get the customers latlong from their browser.
I pass that information to a controller. That controller fills in the City and State (into a location model) using the Google Maps API and then uses it in the view.
So this data is expensive in two ways, first it takes time to look it up and second, in the case of the Google API, it is literally not free in that Google limits the number of calls that can be made per day.
I understand that MVC is designed to "embrace" the web including the fact that http is a stateless protocol.
Nevertheless, I would like to avoid having to fetch this expensive data on every page load for every endpoint that needs it. Furthermore, one other piece of state that I would like to keep track is the fact that the data has already been fetched.
What is the best way / best practice for achieving this on an MVC 3 web application? Since my model for location has 4 data point (lat long city state) and there is a fifth data point (data retrieved) I would really like to avoid using querystrings to do this or a route for all of those data points?
I am sure this is a common need but I honestly don't know how to tackle it. Any help will be appreciated.
Seth
It Seems to me that you would like to cache the API call to google.
http://msdn.microsoft.com/en-us/library/18c1wd61(v=vs.71).aspx
You can store the object you got from google in cache and call it on the new controller event. you could also create another object that has the object from google and a bool that indicates if you have fetched the data or not.
It seem to me that the Cache would be your best bet.
You can store it in session state if it is available in your case instead of passing between pages.
Since this is "expensive" data, but still not to be persisted for a long time, you may:
use Session state
put the data in the Cache and either
set a cookie to enable the retrieval of the "expensive" data from cache
use a cache key which is unique to each query (lat long city state ?)
store the data ("data retrieved") on the client (since you do not seem to persist it on the server side)
My personal preference would be server side cache with a unique key.
Store expensive data to the cache, and build cache ID by parameters you send to google, cache id should be unique for every distinct place
Another option would be html5 storage. You will want to check to see if your target browsers support it though. The advantage to this approach is that the server does not have keep track of this data in session or a database - in fact the server doesn't know about client storage at all.
try
Session[xxx]=xxx;
or
Application[xxx]=xxx;
instead