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

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

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

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

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

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

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

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

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


user-interface asp.net-mvc model-view-controller data-modeling lookup-tables
person Erik Funkenbusch    schedule 12.02.2011    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

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) загружаемыми элементами.

person LukLed    schedule 12.02.2011
comment
Мне нравится, как вы включаете списки выбора в модель представления. Я не уверен, что мне нравится подход словаря. Для меня это слишком сильно пахнет слабо типизированными данными (т. е. можно назначить Employee в качестве типа пола) или подходом с унифицированной таблицей поиска. - person Erik Funkenbusch; 13.02.2011
comment
@Mystere Man: у каждого решения есть недостатки. Создание отдельной таблицы и внешнего ключа для полов кажется слишком сложным. Вы всегда можете добавить ограничение CHECK. - person LukLed; 13.02.2011

arrow_upward
1
arrow_downward

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

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

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

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

person Walter Mitty    schedule 12.02.2011
comment
Да, ты наносишь удар в самое сердце моей дилеммы. Являются ли списки выбора частью модели или нет? - person Erik Funkenbusch; 13.02.2011

arrow_upward
0
arrow_downward

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

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

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

person Jakub Konecki    schedule 12.02.2011