1

I've searched a lot of posts and I have not been able to find a question which addressed my exact specific requirements. Here's what I'm trying to achieve:

Background:

I have a ASP.NET core MVC application. I'm trying to minimize the database trips by reusing the data which are not being changed regularly. I have 2 groups of data which I call Statics and Dynamics

Statics: They never change for the entire application life. (Entity types, Status names, etc)

Dynamics: They are specific for each login. (Business details, list of services, tax details etc. These will be different for each logged in user)

For the Statics, upon application start, I go to the database and store these values in the static fields of a static class. From this point forward everyone have this data without a single trip to the database. So far so good. Statics are being used in all layers; presentation, business, persistence. This saves me tons ot database trips.

My Problme

I want the following behavior for the Dynamics Each time a user logs in, a data container (similar to Statics) is populated for that user only. So for as long as that user is logged in, she doesn't need to go to the database for her needs of anything in the Dynamics

When another user logs in, he gets his own set of Dynamic data container that he can use from anywhere in the application. From all the layers.

How can I achieve this functionality?

The Statics is a class in the Business layer and has it's own data manager which is being called upon application start up.

I need to have a similar setup for Dynamics with its own data manager which is being called upon each user log in to populate the Dynamics and reuse the data for the duration of log in.

Naturally I cannot use a static class and static fields because they will be overridden by each log in and all the other users get the incorrect data.

Many thanks in advance

Manuel.B
  • 81
  • 10
  • Use the Session for this kind of thing, as long as the quantity of data is not too large. P.S. I can't see how you've done this exactly, but I would check what your "statics" example is really doing...it may fetch the static data and store it in memory _for the duration of the current request_, but I doubt it keeps it there in between requests. – ADyson Mar 14 '19 at 23:56
  • Web applications are stateless and usually the values of variables does not persist in between each HTTP request to the server - the script runs from the start each time as if it had never run before. So unless you have structured it a more subtle way than you've described, I think your "statics" may still get fetched quite a lot - once every time the user loads a new page or submits a form. – ADyson Mar 14 '19 at 23:57
  • 1
    The reason why you don't want to hit the db frequently is because the queries take too long to complete? Are you operating at such a high scale that your db provider will fall over? You can use caching strategies i.e in memory or distributed (Redis) but caching is a pain to get right and error prone so you need to weigh up your tradeoffs – JohanP Mar 15 '19 at 00:08
  • @ADyson - he said "static fields in static classes". Those values are scoped to the entire app domain (see https://stackoverflow.com/a/195290/453277). – Tim M. Mar 15 '19 at 00:24
  • 1
    @TimMedora thanks I didn't know that. It's not the case in other languages, e.g. PHP (unless I'm wrong on that one too...but AFAIK it doesn't have the same concept). – ADyson Mar 15 '19 at 00:27
  • If you do not want to make trip to database you can use some caching technique such as memcached. It is a in memory store of data. Store the data in cache once retrieved from database and always check if data available in cache before retrieving from database. When you update the database, make sure the old cached data is either removed or updated with the new data after writing to the database. – Chetan Mar 15 '19 at 00:52
  • Thank you all for your comments. I can confirm that Statics work fine. It's not a high scale problem (yet) but generally if we have a data which stays the same for an entire session it's a good practice to have it available for the duration of a session rather than getting it with each transaction. I'll look into the suggestions for caching approaches and will update if necessary. – Manuel.B Mar 18 '19 at 02:52

0 Answers0