I’m working on a code base that has a lot of identical ConfigurationManager.AppSetting calls scattered throughout.
Does this sound like a possible performance issue?
Or because the data being very small is trivial and not ‘expensive’? Constantly going back to the file to get the data, or does the .NET runtime cache the file/values/calls?
If this isn’t a performance issue is it just a disorganized approach to accessing the application configuration values, and should just be re-factored to be cleaner and consistent implementation of accessing the settings?
I would say it’s more of the code maintainability issue than performance issue. A simple dictionary lookup on
AppSettingsisn’t going to be a problem unless you have code that tries to perform lookup onAppSettingsin a loop that runs say hundred times. Surely such a code will cause performance problem. But even more important is you will haveConfigurationManager.AppSettings["MyKey"]throughout your codebase. You are introducing a magic string. If you have to change the key in your configuration file, you will have to do a thorough search and replace in all your projects. Moreover, we usually make some decision based on the value stored in appSettings. It’s not always straighforward read and use the value as-is. Sometimes you take decision based on the value. For ex,You might be repeating this logic in hundred places. Now let’s say you need to add another condition there:
This gets messy. Your code starts to stink.
So, I always recommend my dev team to never use
ConfigurationManager.AppSettingsanywhere in the code. Use some static class where you read the configuration values and all such decisions are precached into a single variable. For ex,This is not only better in performance, but also highly maintainable and extensible code.