I'm building ASP.Net MVC application "kinda Game" which deal a lot with online users.
I made Ajax request fired every "10s" to some Action to keep user online when he keeps site open.
this Action update LastActivityDate for this User - ((in static List and DataBase)).
So the Question is :
Is it better to store Online Users in static list and write some code when user log in to add him to that list and then keep manage this list every "10s" to kick out the offline users.
Or the best is to load online users
from DataBase whenever i want OnlineUsers.
note: I'm using technique from this SO Question to do some periodically tasks like re-manage OnlineUsers static list.
First, you wouldn't use a List<User> for this, but rather a Dictionary<int,User>, using the user's id as the key, so that you could immediately find the user to update. Second, I think it's probably a mixture of both. You keep a cached copy of the current users, periodically refreshed from the DB, and persist the data (asynchronously, if necessary) to the DB. You might want to think about a custom persistence class for Users that encapsulates this behavior if you find that you're doing this sort of operation in various places in your code.
If you intend on having a large number of users, and you would need to pull data from the DB frequently, it may be better to store a list of users in the Cache. Obviously this will be stored in the server's memory, so you wouldn't want to store a large amount of objects, but if it's just a simple list of online users it shouldn't be an issue.
The scope of static is always the scope of the process that runs in the operating system. So in a desktop application the use of static makes sense. However, I find the use of static a little bit arbitrary for server side applications because you don't control the processes. It's the web server that does this. What if the process ends unexpectedly? Or what if there are many processes that serve your application?
So, the use of the database is unavoidable. Still, you can the static scope as a temporary cache but you cannot rely on it.
Related
I'm trying to determine if I can use Realm DB for an app I am building and I am stuck on access control.
In the Realm DB documentation it looks like the only way to do access control is through Realms themselves, by either granting or revoking access to an entire realm. The documentation also says to try and keep the number of concurrently open and syncing realms to about 12. I am trying to build an app with a social feed where users can "follow" each other, and you could potentially follow hundreds of different users. You see very little data, just their activity, so there is not much actual data going back and forth, but you should only have access to view that data if the other user lets you follow them. I am thinking of it being like each user having a "private" realm and a "shareable" realm that they can grant other people access to. Is there any way to do this with Realm DB that doesn't involve syncing hundreds of different realms?
At the moment, there is no other way than syncing hundreds of Realms.
There will be another way in the future where you can use partial
synchronization.
https://realm.io/docs/java/latest/#partial-synchronization
I am building an extremely simple VB.net web application that uses Visual Studio's forms authentication. As part of this- I am trying to capture the userID upon login and use it while the user is in the app (to dynamically display information via dataset/gridview that is associated with that userID) so I don't have to give them their userID and prompt them for it constantly.
The app is very simple and uses a local DB to do all the authentication (Users, User_Activation, Roles)
This app will have 9-10 users that will be consistent over the years(logging in 10-15 times a year), and 40-50 rotating users that log in once or twice and do not return past that year.
The profiles and authentication/sessions do not need to handle tons of users and authentication requests.
I also want to avoid cookies because I want to keep everything as simple, and centralized to the application as possible.
I have explored building a GetUserID function that queries the database based on the userName every time a user takes an action (button click, page load) that requires the userID. But I am having trouble with the SQL and it seems bulky.
I have also looked into sessions- but they seem unreliable and difficult to manage.(How do i keep each session separate as users login?)
I am now looking at Profiles
https://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
https://msdn.microsoft.com/en-us/library/system.web.profile.sqlprofileprovider.aspx
I think I can just use the default instance of the SqlProfileProvider and point it to my database I already have built?
I am very new to programming and am not sure how complex the configuration would be for the Profiles, so any guidance or advice would be greatly appreciated!
I can post any code snippets needed, or upload the app to github or something if that helps at all.
Thanks!
I have an order system developed on asp.net 4 web forms. I need to store order details (order object) for a user on the cache in order to manage it till I save it in the DB.
I want to install my site at least on two server with option to scale for more in the future .
As you know , the two servers are located behind load balancer , so I need the cached order object to be shared on the both servers.
I hear about App fabric.
Any recommendation to good frameworks to do that , Hope will be simple and easy to maintain one .
Thanks in advance ...
I need to store order details (order object) for a user on the cache
in order to manage it till I save it in the DB.
If your data is not persisted, SQL Server-based Session state will work across machines on a per-user basis and can be configured with a minimum of fuss.
However, I would suggest regularly saving the order to your application database (not just the Session database) so that the user doesn't lose it. This is fairly standard practice on e-commerce sites. Unless the order process is very short, inevitably the user will want to pause and return, or accidentally close the browser, spill coffee into their computer, etc.
Either way, the database makes a good intermediate and/or permanent location for this data.
I'm working on an ASP MVC project using C#.
My question is basically which is the best place to store some data that you get at a given part on your website, say for example, on the method that handles the SignOn of the user to the site, and then you want to access that data on another parts of the website, say on the classes of your model layer.
Suppose the data is just a list of strings, what would be better, store it as a list or wrap the list with a class?
Thanks.
It depends on how long you need your data to be around.
In the case of a single request you could use TempData on the controller
If you only want to store it per session (aka next time the user logs on to the site it will be gone) you could use the Session
If you want to keep it around forever then you will need to use some sort of offline storage, such as a database or file of some sort.
Good luck.
Um, pardon my ignorance, but can't you store it in the database?
What do you mean by "shared"? Shared by whom, by different pages but the same user? Or by different users?
If the latter -> DB.
If the former, either TempData, or if your talking about "authentication" data, then store it in the forms authentication ticket (assuming Forms Auth).
I think similar question was asked before here is the URL
Session variables in ASP.NET MVC
YOU likely store them in a session
which is the best place to store some data that you get at a given
part on your website, say for example, on the method that handles the
SignOn of the user to the site, and then you want to access that data
on another parts of the website, say on the classes of your model
layer.
A database is a great candidate for storing such information. Or a cookie if it is user specific and you don't need it to last very long. Or a file on the server. Or on the Cloud. Or write a P/Invoke wrapper around a C++ unmanaged Win32 function that will deposit the data on your company's intranet FTP server. The possibilities that you have are close to infinity. Just pick the one that you feel most comfortable with.
And I am explicitly not suggesting you to use Session contrary to what others might suggest you.
There are 6 techniques to manage states in ASP.NET 3.5 (as far as I know).
(1) View State
(2) Cross Page Posting
(3) Query String
(4) Session State
(5) Application State
(6) Cookies
Can anyone give me some appropriate examples of situations where I should use these techniques?
For example:
(*) Session State: Personalization, Buy Cart, etc.
(*) Cookies: Saving User Credentials, etc.
There's a lot of factors that can influence this, so I won't comment on all of them. But here are a few pointers:
ViewState - This is useful when you'll be posting back to the same page frequently (something you're practically forced into doing by ASP.Net Webforms). How useful it is exactly changes depending on what kind of app you're building. For public internet sites, it should be used very sparingly. You may even want to turn it off by default. For local intranet sites, it's a great tool — especially for the fewer, heavier, webforms pages.
Query String - Use this to store state that you need to allow the user to bookmark a page or process and come back to much later. Even then, you might want to keep it down to some kind of hash that you can use as a key in a database lookup to avoid a really huge url (though hashes have their own problems). Also, a lot of users like to fiddle with your query string directly, so it can be dangerous to put too much here. It's easy to accidentally expose data to users who aren't supposed to see it this way.
Application State - Remember that this is shared by all users, so use appropriately. Things like view counts can go here.
Cookies - Don't use cookies to store user credentials. They're just plain unencrypted text files. Use cookies to store a key into the session (even here you can and should now use cookie-less sessions) and simple personalization settings that will be specific to that user and browser. For example, my monitor size at work is different from home, and so putting display size/layout settings into a cookie is nice because the settings stick for each computer, but it isn't going to compromise my security any if someone else reads that information.
Now I want to highlight this concept from the "Query String" section:
you might want to keep it down to some kind of hash that you can use as a key in a database lookup
Again, hashes have their own problems, but I want to point out that several items on my list talk (including Query String) about uploading data from the client web browser to the web server: ViewState, Query String, Cookie, and Cross-Page Post. You want to minimize the data that you move from client to server. This concept applies to all of these, and for several reasons:
Pulling data from the client is slow for public internet sites. Even broadband connections typically cripple the bandwidth available for upload. 512Kpbs (still a typical broadband upload rate in many areas) is nothing when compared to the Gigabit Ethernet (or faster) connection that likely sits between your database and your web server. As much as you might think of a database query as slow (and it is), it's still likely a much better way to go than waiting for the same data to arrive from the client.
Keeping the data on the server is cheaper, because you don't pay for the bandwidth required to push it to or from the client, and bandwidth often costs as much or more than your server hardware.
It's more secure, because if done right even when a client's computer or connection is compromised all the hacker has access to initially is a hash key that likely expires by the time he can decrypt it. Of course, if done wrong he can use that key directly immediately, so you still need to be careful.
So for most things, what I recommend is to start out by keeping a database key in the Session and then have code to easily pull what you need from a database based on that key. As you experience bottlenecks, profile to find out where they are and start caching those pages or controls, or keep that data/query result in the session directly.
State management option
View state:
Use when you need to store small amounts of information for a page that will post back to itself. Using the ViewState property provides functionality with basic security.
Control state:
Use when you need to store small amounts of state information for a control between round trips to the server.
Hidden fields:
Use when you need to store small amounts of information for a page that will post back to itself or to another page, and when security is not an issue.
You can use a hidden field only on pages that are submitted to the server.
Cookies:
Use when you need to store small amounts of information on the client and security is not an issue.
Query string:
Use when you are transferring small amounts of information from one page to another and security is not an issue.
You can use query strings only if you are requesting the same page, or another page via a link.
Server Side Management Options
Application state
Use when you are storing infrequently changed, global information that is used by many users, and security is not an issue. Do not store large quantities of information in application state.
Session state
Use when you are storing short-lived information that is specific to an individual session and security is an issue. Do not store large quantities of information in session state. Be aware that a session-state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalability.
Profile properties
Use when you are storing user-specific information that needs to be persisted after the user session is expired and needs to be retrieved again on subsequent visits to your application.
Database support
Use when you are storing large amounts of information, managing transactions, or the information must survive application and session restarts. Data mining is a concern, and security is an issue.
Not sure if you mean the Cache object by Application State.
The Cache object is a great way to manage application wide state, e.g. to record source and count access to your website (to prevent DDOS attacks for example).
(3) Query String
(4) Session State
(5) Application State
(6) Cookies
1. Viewstate
Disclaimer: Use as little as possible. Good point is to always have each state reachable by an url, if possible.
F.e. Paging should use the URL (so /url/?p=2 instead of storing the page in Viewstate)
Use to persist control state between page-cycles.
F.e. Store the selected item in a checkbox, so you can determine whether it has changed.
2. Cross Page Posting
Don't. See the disclaimer for viewstate. Use the URL for this, or store the data in a session / cookie / profile if loads of properties need to be kept around.
Major downside of CPP is that the user cannot use the 'Back' and 'Forward' buttons in it's webbrowser. When a user clicks the back button it wants to undo everything on that page and retry the last one. When using CPP to click them through a wizard; this behavior is not possible without a lot of 'Are you sure you want to resend blablablabl'.
3. Query String
Use alot. Every visible state that a page could reach should be accessible by URL. People with screenreaders will thank you for this. And by using the query string there is no need to use javascript-only solutions.
/url/?page=2 // when doing paging, don't use postback for this
/url/?tab=advanced-search // when having tabs on top of your page
etc.
4. Session state
Use this for short-living objects, that only make sense this time the visitor visits your site. For example:
Which step of a certain wizard was reached
Pages a user had visited before
Small objects you want to put in cache, but that are user-bound
Don't use sessions but profiles for things like:
Preferences
Selected language
Because those things also make sense the next time the user visits your site.
5. Application state
Never. Use ASP.NET cache, or memcached, or any caching framework for this.
6. Cookies
Session ID, Profile ID for authenticated users; user preferences for anonymous users (everything listed in the second list under 4.).