2

I'm converting an application from C# WebForms to MVC.

The application gets settings from a centralized location using Web Services. These are settings you would typically find in a Web.Config, but the desire of the company is to store these values in a centralized location for all apps.

Currently, any time you request an application setting, it checks HttpContext.Cache to see if you've already retrieved the settings. If you haven't, it makes the web service call, and stores the settings (100+ objects that are essentially key/values) in the HttpContext.Cache. So the call to get application settings only occurs once.

Should I be looking at another way to do this? I was thinking the settings should just be a REST service call where you pass the key and get a value (the current service is an *.ashx which is really not ideal for exception handling amoung other reasons). But obviously this would result in more web requests. What is considered a best practice here? Is the current method fine and I should just leave the code working the same in the MVC app?

  • What is the motivation for looking at a different method for doing this? – Robert Harvey Sep 17 '14 at 16:29
  • 1
    Under what circumstances, and how often do these get changed? How do you currently deal with the differences in cache expiration over time? – Bill Sep 17 '14 at 23:23
1

The current approach seems reasonable. It's basically lazy loading the settings on first call and is "chunky" -- sending back all settings at once. Your proposed approach is more precise but is "chatty" -- multiple calls may be needed to get what you require. The two questions I would ask are:

  • Does the "chunky" version take up too much memory?
    Assuming you only need a small percentage of all the configuration objects. Could you save a significant amount of memory (which depends on your platform) by not loading everything? Is that amount of memory going to affect performance or app/host stability?
  • Does the "chatty" version cause too much latency?
    Is it possible that you may have to make 15 calls to the configuration service to handle the first request? What kind of wait time will that cause the user?

From experience, I would likely choose the chunky communication, especially since you already have it written.

If you do get a chance to change it, consider a precise but chunky request where you request all settings used by your application at once. That would give you the best of both worlds. However, it better be worth it, because you will still have to maintain a list of required setting keys in your application. There's nothing quite so infuriating as spending a while debugging your code only to realize you forgot to add the setting key to the request list. If code tries to access a missing key, make sure you provide a clear error message!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.