0

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.

Vic
  • 2,878
  • 4
  • 36
  • 55

4 Answers4

2

It depends on how long you need your data to be around.

  1. In the case of a single request you could use TempData on the controller

  2. 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

  3. 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.

shenku
  • 11,969
  • 12
  • 64
  • 118
  • Be very clear about the scope of this data (request vs. session) then follow shenku's advice. My only add is to consider in memory cache such as memcached, redis or appfabric if you want to share things between servers. – hoserdude Feb 24 '12 at 00:06
1

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).

RPM1984
  • 72,246
  • 58
  • 225
  • 350
0

I think similar question was asked before here is the URL Session variables in ASP.NET MVC YOU likely store them in a session

Community
  • 1
  • 1
COLD TOLD
  • 13,513
  • 3
  • 35
  • 52
0

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.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • sometimes session simply cannot be "reasonably" avoided. The only place i use it is if a user tries to submit some data (eg form), but are not logged in, so i need to re-direct to the signup/login page, then show the pre-filled data again after the redirect. Only alternative is to store "temporary" data in the db (e.g save, get it out, delete) which is overkill. – RPM1984 Feb 23 '12 at 23:02
  • @RPM1984, of course that a session can always be avoided. I am always avoiding it. As far as the scenario you are describing is concerned, well, there are so many other ways to achieve it, such as cookies, HTML 5 sessionStorage, ... – Darin Dimitrov Feb 23 '12 at 23:05
  • i guess i could use cookies, but it's still "session" albeit client-side. As for HTML5 dom storage, how would that work? How would i get the form data from the form to the signup page, then back again? Remember, it's a POST, then a GET (redirect to login page), then a POST (login), then another GET (back to original page). Plus with a cookie, you have to explitly destroy it (or leave it hanging around). At least with TempData it's auto-remove after the read. Anyway, we could go on all day. I know your feeling on session. :) – RPM1984 Feb 23 '12 at 23:15
  • @RPM1984, exactly, cookies are `client side session`. That's exactly what makes them great. Now your application is completely stateless. You can throw in/out as many nodes as you want in your webfarm and your site will work correctly. As far as HTML5 sessionStorage is concerned, it has pros and cons compared to cookies but could be a great replacement. You might just need to have your hands a little dirty with javascript. And yeah, we could go on all day about session. So let's just not do that as have no such intentions :-) I have thrown my 2cents, you have thrown yours, end of story. – Darin Dimitrov Feb 23 '12 at 23:17