Should DropDownList items be part of the model?

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.

Answer 2

If you have a large list and need to filter it dynamically on the server then you need an ajax call to your Action.

If you want to render a select with a bunch of options or just a json array of values which you will filter on the client-side then I would recommend adding drop-down items to your ViewModel and populate this collection in Controller. The list may be hard-coded for the time-being but you can make it dynamic (ie. read from database) later on by just modifying your controller without touching ViewModel or UI at all.

Check out this link for some code sample: http://odetocode.com/blogs/scott/archive/2010/01/18/drop-down-lists-and-asp-net-mvc.aspx

Answer 3

I'm going to rephrase your question. The model is the model. If a collection of alternatives are part of the model, then they are part of the model regardless. The data model has an internal consistency and integrity, regardless of how implemented.

So then the question becomes, should sets of alternatives that have been included in the model ever be implemented as drop-down lists? My answer is yes, sometimes.

With regard to a case like "gender", the question is, "how likely is there to be additions to the set of genders in the near future?" If it's very likely, you might be better off paying for the round trip. If the chances are zero, you are probably better off hard coding the choices into the UI.

Years ago, I would have said that additions to the set [Male, Female] would have been completely unlikely. Today, there are people who opine differently.