Best way to handle shared configuration settings between Web Parts?

Question

Let's say I have several web parts as part of a solution, all of which need to look up certain information in some list. Within the code, they need to know the name of the list to use TryGetList (or equivalent for GetList or whatever). And if the list name changes, or a completely new list needs to be used, the web parts need to be told to change were they are looking. The options as I see them:

1. In the code as constants (defined in one place)

Pros:

Presumably the best performance

Single place to update

Cons:

Updating requires changing the code and redeploying the solution

2. As a property in SharePoint’s web.config

Pros:

Single place to update

Update can be done on a web app without redeploying the solution

Cons:

Requires Powershell to perform the update

3. As properties of the Visual Web Part

Pros:

Updates can be done through SharePoint’s UI via Edit Page

Cons:

Update would need be done separately for each web part

4. As a new list

Pros:

Updates can be done using the usual list interface

Cons:

Presumably the worst performance as it adds an additional query to the config list

Having to redeploy or remember multiple places that need to be updated both seem like big enough issues that 1 and 3 are just bad options. Are the performance differences between 2 and 4 significant, either in terms of X seconds longer every time the page loads, or in terms of if the web part runs Y times causing Y queries to the config list, once Y is large enough it might slow down the whole server? Am I missing anything about these options or missing options?

Answer 1

From maintenance as well as performance I recommend the use of a Configuration Custom List.

During the first request, you can pull the configuration values and store it in either SPWeb property bag. Or user HTTPCache.

You can decide a time-frame on how long the cached value should be stored (like read the configuration value after 24 hours etc.)

Answer 2

Microsoft's pattern and practices group has published guidance, including a hierarchical configuration manager library. The library uses a list or property bags. You can read more at http://www.microsoft.com/spg.

(I would avoid web.config - the change management process for web.config in SharePoint is not reliable.)

Answer 3

web config is evil. hardcode is evil even more.config list might be feasible if you have something to store there, not just a shared list url - I would go that way, especially with a sweet bonus of cloud compatibility if you decide to migrate to apps model in the future. WP properties is probably right way to do it, but as always it depends on how many places and how often you need to update to maintain the solution: sometimes better to go with easiest approach ;)

Answer 4

You can keep this data in site/sitecollection property bag.