title: Best practice for persisting database-stored lookup data at app level in MVC
body: <p>Slogging through MVC+EF and trying to focus on doing things the right way. Right now I'm looking to add a dropdown to a form but I'd like to avoid hitting the database every time the page loads so I'd like to store the data in the app level.  I figure creating an application level variable isn't the best approach.  I've read about using the cache and static utility functions but surprisingly, nothing has sounded terribly definitive. (Static classes bad for unit testing, caching bad </p>
  
  <p>So I have two scenarios that I'm curious about, I'm not sure if the approach would differ between the two.</p>
  
  <p>1) A basic lookup, let's say the fifty states.  Small, defined, will never change. Load at application startup. (Not looking for a hard coded solution but retrieval from the database.)</p>
  
  <p>2) A lookup that will very rarely change and only via an admin-like screen.  Let's say, cities/stores where your product is being sold. So data would be stored 
  in the model but would be relatively static unless someone made changes via the application. So not looking to hit the database every time I need to populate a dropdown/listbox.</p>
  
  <p>Seems like basic stuff but it's basically the same as this topic that was never answered:</p>
  
  <p><a href="https://stackoverflow.com/questions/1990876/is-it-good-to-use-a-static-ef-object-context-in-an-mvc-application-for-better-pe">Is it good to use a static EF object context in an MVC application for better perf?</a></p>
  
  <p>Any help is appreciated.</p>