Должны ли элементы DropDownList быть частью модели?

Question

Что-то, с чем я борюсь, более философски, я полагаю, является ли элементы DropDownList (или действительно любые элементы списка выбора) частью модели, или они должны быть жестко закодированы в пользовательском интерфейсе или бизнес-уровне.Или, может быть, это хорошее использование ViewModel?

Для некоторых видов выпадающих списков вам, очевидно, нужно сделать их частью модели.Например, модель должна сгенерировать выпадающий список идентификаторов заказов, связанных с клиентом.

Другие виды, которые я бы назвал «поисковыми» данными, для меня менее понятны.Пол, например.Зачем использовать поиск в оба конца, чтобы заполнить поле двумя элементами?Возможно, это преждевременная оптимизация, но если у вас есть 50 полей, это много циклов, чтобы заполнить одну страницу.Конечно, кеширование там может пригодиться, но это кажется грязным.

Я также беспокоюсь, что добавление всех этих списков поиска в модель излишне захламит его.Особенно, если у вас их много.

Существует также возможность не жесткого кодирования в пользовательском интерфейсе, а жесткого кодирования на бизнес-уровне.Возможно, даже создание класса, который ничего не делает, но заполняет эти данные.

Если ответ таков, вы все равно должны сделать их частью модели данных, тогда возникает проблема того, должна ли ваша модель данных иметь другую таблицу длякаждый набор полей поиска.Если ваша модель данных имеет 200 или 300 таких полей, то это 200 или 300 таблиц, и это действительно усложняет ведение вашей модели данных.

Я задал вопрос о наличии общей справочной таблицы некоторое время назад, и все согласились с тем, что это плохая идея.Но для приложений с большим объемом данных, где много областей, я сомневаюсь.

Теперь я знаю, что многие из вас скажут: «Это зависит», но я смотрю на «в целом».такой ответ.Вообще, какое здесь эмпирическое правило?

Answer 1

Я участвовал в создании одной системы с большим количеством словарей. Большинство из них были сохранены в одной простой таблице, которая содержала идентификатор словаря, идентификатор элемента, его имя и некоторые другие основные значения. У некоторых элементов в этой таблице были предопределенные идентификаторы (например, мужской = 1001, женский = 1002), поэтому, если в таблице было поле пол_дня, мне не нужно было искать в таблице словаря для поиска мужчины, я знал его идентификатор. Эти идентификаторы все еще были определены в коде как константы, но для целей представления они были взяты из базы данных. Это работало хорошо, и производительность была неплохой (сотни словарей, тысячи предметов). Они могут быть переданы для просмотра в виде модели. Просмотр модели для редактирования человека может выглядеть так:

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

Вы можете заполнить представление кодом:

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

, где Dictionaries - это перечисление.

В методе DictionaryService.GetDictionary() вы можете ввести какое-то кеширование.

Если вы хотите заполнить раскрывающийся список, который может содержать неограниченное количество элементов (для полей, которые ссылаются на другие таблицы, которые значительно растут во времени), используйте какой-либо инкрементальный поиск с динамически загружаемыми (ajax) элементами.

Answer 2

Я перефразирую ваш вопрос.Модель есть модель.Если набор альтернатив является частью модели, то они являются частью модели независимо.Модель данных имеет внутреннюю согласованность и целостность, независимо от того, как она реализована.

Итак, возникает вопрос, должны ли когда-либо реализовываться наборы альтернатив, включенные в модель, в виде раскрывающихся списков?Мой ответ да, иногда.

Что касается случая, подобного «полу», то возникает вопрос: «Насколько вероятны дополнения к набору полов в ближайшем будущем?»Если это очень вероятно, вам лучше заплатить за поездку туда и обратно.Если шансы равны нулю, вам, вероятно, лучше жестко запрограммировать выбор в пользовательском интерфейсе.

Несколько лет назад я бы сказал, что добавления в набор [Мужчина, Женщина] были бы совершенно маловероятными.Сегодня есть люди, которые думают по-разному.

Answer 3

Если у вас большой список и вам нужно динамически фильтровать его на сервере, вам нужен ajax-вызов для вашего действия.

Если вы хотите визуализировать выборку с набором опций или просто массивом значений json, которые вы будете фильтровать на стороне клиента, я бы рекомендовал добавить раскрывающиеся элементы в вашу ViewModel и заполнить эту коллекцию в Controller. Список может быть жестко запрограммирован на данный момент, но вы можете сделать его динамическим (то есть читать из базы данных) позже, просто изменив свой контроллер, не касаясь ViewModel или пользовательского интерфейса вообще.

Проверьте эту ссылку для некоторого примера кода: http://odetocode.com/blogs/scott/archive/2010/01/18/drop-down-lists-and-asp-net-mvc.aspx