Question

I’m creating an ASP.NET MVC app that uses EF to perform all DB tasks.

There’s a couple of related tables in the database that never change and I was thinking on creating a static collection that retrieves the data from those two tables (it’s a few hundred records) the first time it is requested and just stores it in an object to prevent hitting the database every time.

Since I’ve read several people saying that you should avoid static objects in ASP.NET I was wondering if this was a bad practice or if it is acceptable for scenarios like this (read-only and small amount of data which should prevent concurrency problems).

Also I would like to know if there are other better alternatives to do this.

Thanks.

Answer 1

I have done exactly what you are planning on doing for exactly the same reason. It has been working well for several years already.

Just make sure that you get the initialization of the data right and you should be fine. When initializing, keep in mind:

• Don’t use locking if at all possible (or your app will deadlock 2
  minutes before you’re going on vacation)
• You MUST NOT under any circumstance let a static constructor fail
• Make sure no consumer of your cache has the ability to modify it

If the data isn’t really static and you would actually need to re-read it fairly often then this might not be the best solution.

Just in case you’re wondering, I’ve used this approach to cache for instance country data, currency data (base data, not rates), sales unit data (pcs, m, kg etc). These are all stored in a database but almost never change.