0

i am writing a database app that returns recordsets to my controller. i would like to reuse them because they are static data, (based on user, different for every user), and resort/search as needed using Linq based on multiple requests from a user.

in the past, Session variables were highly frowned upon, even taboo, in ASP.NET MVC because one of the benefits of the technology was that it was supposed to be fire and forget. now i am seeing more people suggesting using Session variables to hold recordsets.

is this the standard now, or is there a better way to handle multiple requests that would use the same recordsets? for example, should i make a local service to hold the data that would only service my ASP.Net MVC application? something else?

Amit Kumar Singh
  • 4,393
  • 2
  • 9
  • 22
newbieprogrammer
  • 19
  • 1
  • Who is suggesting this and in what measures are they suggesting it's better? Many people suggest many things. Every suggestion isnt taken seriously. Formulate your question to be more specific and allow for an objective answer. – jamesSampica Sep 14 '17 at 03:53
  • Is a Session object appropriate to hold a recordset for use over multiple user interactions in an ASP.Net MVC application -- or should i create a separate local C# project to act as a data layer that would only act as a service to the ASP.Net MVC application? users could then be tracked by an id. OR something else? – newbieprogrammer Sep 14 '17 at 03:57
  • 1
    By what measures? memory? speed? How big is the recordset? What's it used for? What is appropriate is subjective and depends on the context it's used in and what the alternatives are. – jamesSampica Sep 14 '17 at 04:05
  • Whoever frowns upon them, frown right back on them. Sessions have their place and use. – CodingYoshi Sep 14 '17 at 04:31

2 Answers2

1

You can use a session object. If you want to continue to use session, check this link. It has better ways if implementing the same. Also, it will be not of much use if you store session itself in SQL server. In that case, it will be better to store it in a different session user table as a JSON string maybe.

If you have low number of users in session at all points in time, like it is an application internal to some company, you can use Flyweight design pattern with a dictionary behind a singleton to bring the Dictionary<string,object> and get the data at all times. Check the singleton sample here.

If you want a scalable application with high number of users, check the following as well.

You can use memory cache as Object Cache also under System.Runtime.Caching, by user key, and if it is not in cache, bring from database.

You can also use out of process caching like redis and memcached, or AppFabric Data Caching, if you are on windows server environment.

Then, you can have noSql databases, like mongoDB, for storing only session data on the server. Clear the session data if no activity after some time.

Amit Kumar Singh
  • 4,393
  • 2
  • 9
  • 22
1

In general, session is frowned upon because of its limitations. For instance, it's highly serialized and can greatly impact performance, although using attributes to make session read-only can improve that. Another issue is that session is volatile, and can literally go away whenever IIS wants more memory. It's also not secure, nor should it be used for anything secure.

A better option might be using the asp.net cache to store the data, or even HttpContext.Items array if you only need it on a per request basis.

Session is also a scaling issue, if you need to expand to multiple servers.

In general, only use session for smaller apps that won't have a lot of demand.

If you do use Session, then I suggest abstracting access to it, so you can change the actual storage mechanism easily at a later time if you find Session to be non-performant.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291