Hard Code List of Years?

This is the scenario. You've got a web form and you want to prompt the customer to select their birth year.

a) hard code the values in the dropdown list? b) Grab valid years from a DB table

I can see a maintenance nightmare with copying a set of years hard coded in .aspx files everywhere.

updated:

for loop is not ideal (maintenance nightmare and error prone). The user then has to sift through 120 years that haven't even got here yet.

I still like the DB approach:

* Single point of data
* No duplication of code
* Update the table as needed to add more years
* Year table values could be used for some other dropdown for some other purpose entirely for something other than Birth year

Simple as that. No need to go updating code everywhere. I feel for data that is universal like this, we shouldn't be hard coding this shiza into a bunch of pages which is totally going against reuse and error prone...really it's not pratical. I'd take the hit to the DB for this.

Updated (again...after thinking about this):

Here's my idea. Just create a utility or helper method called GetYears that runs that loop an开发者_JAVA技巧d returns a List<int> back and I can bind that to whatever I want (dropdownlist, etc.). And I like the web.config idea of maintaining that end year.

C) Use a for-loop to generate the years in a range of your choice.

Something as simple as this pseudocode:

for (int i = 1900 ; i < THIS_YEAR - 13 ; i++)
{
    validyears.options.Add(i);
}

Neither - provide a centralized service which can decide which mechanism to use, then the application doesn't care, and you are free to choose hardcoding, sliding window or database mechanisms.

To expand, typically, I would do something like this:

1. Define IPopulatableYear interface which has a single AddYear method taking an int and constructing an appropriate ListItem or whatever.
2. Make MyYearListBox inherit from regular ListBox implement IPopulatableYear (this works for winForms or WebForms)
3. Create static method or singleton or method in your DAL or whatever.

Like this:

PopulateYears(IPopulatableYear pl) {
    // Very simple implementation - change at will
    for (int lp = 2009 ; lp < 2009 + 10 ; lp++) {
        pl.Add(lp);
    }
}

or

PopulateYears(IPopulatableYear pl) {
    // A DB implementation
    SQLDataReader dr = DAL.YearSet() ; // Your choice of mechanism here
    while ( dr.Read() ) {
        pl.Add(dr[YEAR]);
    }
}

or

PopulateYears(IPopulatableYear pl) {
    // A DB limits implementation with different ranges defined in database by key - key determined by control itself - IPopulatableYear needs to implement a .YearSetKey property
    SQLDataReader dr = DAL.YearLimits(pl.YearSetKey) ; // Your choice of mechanism here
    for ( int lp = dr[YEAR_MIN] ; lp <= dr[YEAR_MAX] ; lp++ ) {
        pl.Add(lp);
    }
}

The mechanism is now centrally managed.

Use MyYearListBox on your forms and call PopulateYears() on it. If your forms are smart, they can detect all MyYearListBox instances and call it, so you no longer have any new code - just drag it on.

Take a look at Enumerable.Range. I think making DB calls is FAR less performant than Enumerable.Range.

E) Use a text input box, because that will always work.

(Be sure to validate it, of course, as a number. Include "Y2K" and "The year World War II started" in a dictionary of years, of course.)

How you present the year selection in the web form is irrelevant. It's an interface decision. Your server should not trust the data coming in, and should validate it accordingly. It's trivial to emulate a form submission, so it doesn't matter how it's presented. Heck, you can generate the drop down with javascript so there is no load on the server.

You can validate with a rule on the backend, rather than a lookup.

Since you're raising this whole issue (and making a bunch of comments), maybe it's within your power to think long and hard this.

For the end user, it's hard to beat the ease-of-use of a text box. Yup, you're going to get bogus data, but computers are supposed to make things easier, not harder. Scrolling through a long list of years to find the year I know I was born is a nuisance. Especially with all those young whippersnappers and old farts who want to enter birth years that aren't anywhere close to mine!

But stepping back even further...do you really need to ask the user their birth year in the first place? Is it that important to your application? Could you avoid the issue entirely by letting somebody else deal with that? Say by using OpenID, Windows Live ID or Facebook Connect?