Hi Al,
That's a common scenario but you have to be careful you understand the implications of globally caching data. If the data changes you usually have to restart the app or have a routine that reloads the static data.
You might also want to look at the Cache object which is similar to application state but gives teh option of releasing content at timed intervals and then forcing to reload it. While this is a little more work - you usually need a wrapper method that checks the cache and if not found reloads the data - it offers more options and lets you deal with data updates transparently. If you're caching data the assumption is that the data is 'busy' data that is used frequently so caching even for short periods of time (like 1 minute) should have significant benefit while still supporting the ability to flush the cache automatically.
If you truly want to have static data that doesn't change ever during the run life cycle of the app, you might also consider static properties which tend to be more efficient than Application State data because they are directly acessed and are strongly typed. These can be loaded from static constructors or special loader methods (which is usually the better approach anyway to allow you to reload if necessary).
>Store an Array:
>- Create a SqlDataReader on the view
>- Spin through the view, adding rows to a string[,] Choices array (downside - would need to cast the int pkeys to strings, then restore later?)
>- Application["arChoices"] = Choices
>- Is it simple & efficient to populate the dropdown list choices from this array?
>Store a DataTable:
>- Is it possible to persist these in Application State?
>- Would it be efficient/elegant to use one to help populate the dropdown lists?
If you reuse data I would recommend you just create a DataTable or Dataset with your data and cache that. Once you have the data take advantage of the features that the DataTable/Set provides for the data and you can more easily bind to it using ASP.NET's built in databinding.
Application State doesn't serialize - it's just a Hashtable with links to the reference object, so they are in fact the live object, so any type can be used to store in Application/Cache objects. Session objects you have to worry about serialization if you use State Service or Sql State. For more info on the storage mechanisms see here:
http://west-wind.com/weblog/posts/1214.aspxHope this helps,
