title: Should DropDownList items be part of the model?
body: <p>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?</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>I also worry that adding all these lookup lists to the model will unnecessarily clutter it.  Especially if you have a lot of them.</p>
  
  <p>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.</p>
  
  <p>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.  </p>
  
  <p>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.</p>
  
  <p>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?</p>