Best practice for binding the 50 states to a combo box

[Ethan V]

I have a few options regarding populating the state combo box

1. On page load, get the 50 states from the database
2. On application start, get the 50 states from the database and cache them
in application cache. On page load, get the states from application cache
3. Create a class in App Code folder, declare a public string array
property, hard code the 50 states. On page load, call this property to get
the 50 states
4. Create a states user control which contain a combo box, with 50 states
hard coded in design time

Please share with me how you usually bind your states combo box. Your
thoughts and recommendations are greatly appreciated.

 

[Kevin Spencer]

Hi Ethan,

Number 1 and 2 are too expensive. The state names never (at least almost)
change.

Between number 3 and 4, I prefer number 4 as the least expensive in terms of
resources, although I'd probably go with a custom Server Control (for easy
reusability between projects).

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.

 

[sloan]

If your "state" example is specifically a state example, then I'd probably
put them into a strongly typed dataset, and have the .xml to populate the
dataset handy.

Thinking outside of the State example. where you have a look up table...
that ~maybe changes every blue moon (in the db), then I usually do this:


1. Check the Application (or Session) for an existing copy.
2. If it doesn't exist, then read a fresh set out of the db, and put them
into the Application or Session object.
3. Return the Appliacation (or Session) copy.

I usually throw a "bool forceRefresh" parameter on it also. For that seldom
case that I make a change.
(Like, lets say I add a new state to the database. I'd call the function
with a "true" to make sure I refreshed the Application (or Session) data.



public ICollection RetrieveGoodEnoughStates( bool forceRefresh )

{

string keyname = "STATES";

ArrayList states;
bool readValuesFresh = false;

if (forceRefresh)
{

readValuesFresh = true;
}
else
{
if (null!=Session[keyname])
states = Session[keyname] as ArrayList;
}
else
{
readValuesFresh = true;
}

if (readValueFresh || null==states)
{
states = GetTheStatesFromDatabaseSomehow();
Session[keyname] = states;
}

return states;
}

Soemthing like that. YOu can clean it up, but you get the idea.

Check my blog:
http://sholliday.spaces.msn.com/ 10/24/2005 entry

for a object wrapper. Using this, I never use Session["keyname"], I use the
somewhat nicer wrapped object.

You could easily convert this to an ApplicationDataStore

 

[PeterKellner]

Hi Ethan,

Number 1 and 2 are too expensive. The state names never (at least almost)
change.

Between number 3 and 4, I prefer number 4 as the least expensive in terms of
resources, although I'd probably go with a custom Server Control (for easy
reusability between projects).

Hi Kevin,

I'm curious if you are confident that creating a string array in code
is more efficient than cache. Both take up the same amount of server
memory I think and with Cache, there is no object type allocation on
each request. I've always used Cache for this type of thing, but am
willing to change if it's not the right way to go.

Peter Kellner
http://peterkellner.net

 

[bruce barker \(sqlwork.com\)]

making decisions should be based on code reuse. look at these scenarios:

1) these is only one dropdown the app and its for states. no need to do more
then hard code the list
2) the only dropdown in the app is state, and its on several pages. well
this kinda begs for a state dropdown control
3) you have lots of dropdowns and they get reused. this begs for a common
data repository with common load routines. here performance issues may lead
to a common cache.

-- bruce (sqlwork.com)

 

[neilmcguigan]

What about internationalization issues?

What if your boss wants a Spanish version next year?
What if your boss wants Canadians (now with Provinces!) to use your app
next year?

1. think about resources
2. use the cache and buy more cheap ram
3. separate data from presentation
4. code for clarity first, then performance if it's an issue

 

[Ethan V]

Thank you so much everyone for your inputs. I am amazed at the responses I
got because your suggestions not only help me solve this particular
implementation, but they also touch on best practices philosohpy. Thanks so
much again everyone.