ObjectCache to make a variable available to all users

This is an example of the use of objectcache and the variable is available to everyone in the application pool:

if (cache[Cache.Key.PesquisaGrupoProjetos.ToString()] != null)
    grupos = ((IList<EstruturaSIIMDTO>)cache[Cache.Key.PesquisaGrupoProjetos.ToString()]);
else
{
    grupos = db.Get(new ConsultaGrupoProjeto()).ToList();
    cache.Set(Cache.Key.PesquisaGrupoProjetos.ToString(),grupos,DateTime.Now.AddMinutes(720));
}

What is good for you in the specific situation only you can say. Even if you put too many details together it can still be difficult to say precisely what is best because any detail omitted, even for lack of knowledge of it, can change the recommendation.

It looks like you're on the right track. I do not know if it is the best but use an implementation of ObjectCache is something that will get the desired result, as long as done correctly, of course.

Just note that this is an abstract class, so you'll either have to use a concrete implementation of it or create your own implementation. You probably want to use an existing one and it looks like you want to do this in memory. So in practice you'll use MemoryCache . Then your entire application will work within the protocols of this class to handle the cache. Which is good because it was thought by professionals who understand the subject and know how to make it work the best way. You should only do your own implementation if you really need something specific that another does not and knows what you are doing. Even in this case, using ObjectCache as a base is still desirable.

It's good to see that you're avoiding more specific caching like the System.Web.Caching.Cache that depends on the "classic" ASP.Net that was a dependency on ASP.Net MVC but is no longer on newer versions and ideally do not use anything that is not "universal" .Net.

There are other ways to create a cache in ASP.Net MVC but it depends on what you are doing there. Many are very specific. There are options where you write down the cache in setting properties in < in> controller . It has a third-party framework with several options for every need.

If you intend to have your code scalable, then the best thing to do is use a database.

Placing data in a web application statically in the process memory that is serving a request is not good practice . Unless you intend to implement a ObjectCache that reads and writes to BD yourself, you will be limited to MemoryCache which does exactly what I said earlier. (there is an implementation of ObjectCache distributed called NCache , read below).

• What happens when there is more than one process serving requests?

What happens if there is more than one server behind a load balancer? This happens on the Azure platform for example.

But then you could argue that the database is slow ... but the truth is it is not. Most applications read from the database, on all requests. In addition, you can use multi-level caching strategies: using memory and database at the same time, when the need arises.

The question is ... Why not start with the safest? That works in all cases, and then the measure of the need to optimize the cache, migrate to a mixed approach, install a cable between the web server and the BD server, migrate to Azure, Amazon, etc ... there are so many options to optimize this.

Distributed Cache Technologies

They are the best options as they are made to work even in distributed environments.

• NCache : Distributed implementation of ObjectCache , has free paid and open versions . It's even in GitHub .

• memcached : popular distributed caching solution, requires a client for .Net:

  • enyim : It seems like the strongest option
  • nmemcached
  • beitmemcached

• couchbase

I strongly recommend that you use a Cache service, such as Redis that Azure Cache uses.

So you guarantee that the cache will coexist even in scalable environments, and also does not mix the responsibilities, such as using the application database as a temporary repository of your cache.

See more about Azure Cache .

See more about Cache Redis .