Question

Something I am struggling with, more philosophically I suppose, is whether DropDownList items (or really any kind of selection list items) should be part of the model, or if they should be hard coded into the UI or business-layer. Or perhaps this is a good use of the ViewModel?

For some kinds of dropdownlists, you obviously have to make them part of the model. For instance, a dropdownlist of order id’s associated with a customer will have to be generated by the model.

Other kinds, which I would refer to as “lookup” data are less clear to me. Gender, for instance. Why force a round trip lookup to populate a field with 2 items? Perhaps this is premature optimization, but if you have 50 fields, that’s a lot of round trips just to populate one page. Certainly, cacheing might come in handy there, but it seems kludgy.

I also worry that adding all these lookup lists to the model will unnecessarily clutter it. Especially if you have a lot of them.

There is also the option of not hard coding in the UI, but hard coding in the business layer. Possibly even making a class that does nothing but populate this data.

If the answer is, you should still make them part of the data model, then there is the problem of whether your datamodel should have a different table for each set of lookup fields. If your data model has 200 or 300 such fields, that’s 200 or 300 tables, and that really makes maintaining your data model more complex.

I asked a question about having a common lookup table a while back, and the consensus was that this was a bad idea. But for very data heavy applications where there are a lot of fields, i find myself doubtful.

Now, I know many of you will say “It depends”, but i’m looking at a “in general” kind of answer. In general, what is the rule of thumb here?

Answer 1

I’ve been participating in building one system with a lot of dictionaries. Most of them were stored in one simple table, which contained id of dictionary, id of item, its name and some other basic values. Some of the items in this table had predefined ids (for example male = 1001, female = 1002), so if table had gender_id field, I didn’t have to make a lookup in dictionary table to search male, I knew its id. These ids were still defined in code as constants, but for presentation purposes, they were taken from database. It worked well and performance was not bad (hunderds of dictionaries, thousands of items). They could be passed to view in view model. View model for editing person could look like:

public class PersonViewModel {
    public Person Person { get; set; };
    public SelectList Genders { get; set; };
    public SelectList Departments { get; set; };
    public SelectList Positions { get; set; };
}

You could populate view with code:

Genders = DictionaryService.GetDictionary(Dictionaries.Genders);
Departments = DictionaryService.GetDictionary(Dictionaries.Departments);
Positions = DictionaryService.GetDictionary(Dictionaries.Positions);

where Dictionaries is enum.

In DictionaryService.GetDictionary() method you can introduce some kind of caching.

If you want to populate dropdown, that can have unlimited number of items (for fields, that have reference to other tables, that grow a lot in time), use some kind of incremental search with dynamically (ajax) loaded items.