Ответ 1
OK Я решил взять свой собственный совет, и это должно быть определено в контроллере:
FYI, я только что вернулся:
PageData data = new PageData()
{
Formats = new[]
{
new { ID = "string", Name = "Text" },
new { ID = "int", Name = "Numeric" },
new { ID = "decimal", Name = "Decimal" },
new { ID = "datetime", Name = "Date/Time" },
new { ID = "timespan", Name = "Stopwatch" }
},
.............
};
return View(data);
... (игнорировать контекст) и на стороне View ASPX:
<%= Html.DropDownList("type.field", new SelectList(ViewData.Model.Formats, "ID", "Name"...
Если у кого-то есть более оптимальный способ сделать это, я буду рад принять их ответ.
Ответ 3
Все MVC noobs изначально избегают слова "M", но оно начинается с начала акронима MVC. Так что, может быть, просто, может быть, вы захотите начать свое решение с помощью модели... просто говоря.
Не повторяйте себя (DRY). Вы собираетесь копировать и вставлять "новый файл PageData()" для каждого контроллера, который передает список опций в представление. Затем вам захочется удалить или добавить параметр и отредактировать каждый файл данных PageData..
Кроме того, вы хотите ввести наименьшее количество кода с наименьшим количеством ненужных подробных "add", "new", "IS" и "Name". Поскольку у вас есть только пара ключевых значений в опции выбора (и/или список переключателей), используйте самую легкую структуру данных, то есть словарь - в вашей модели.
Затем просто ссылайтесь на модель в контроллере и преобразуйте словарь в SelectList в представление с помощью DropDownListFor, содержащего выражение LINQ Lambda.
запугивают? Ты не один. Я определенно был. Вот пример, который я использовал для обучения M, V и C:
Модельная часть MVC:
using System.Web.Security;
using System.Collections.Generic;
using System.Text;
using System.Linq.Expressions;
using System.Web.Routing;
using System.Web.Helpers;
using System.Web.Mvc.Html;
using MvcHtmlHelpers;
using System.Linq;
// EzPL8.com is the company I work for, hence the namespace root.
// EzPL8 increases the brainwidths of waiters and bartenders by augmenting their "memories" with the identifies of customers by name and their food and drink preferences.
// This is pedagogical example of generating a select option display for a customer egg preference.
namespace EzPL8.Models
{
public class MyEggs
{
public Dictionary<int, string> Egg { get; set; }
public MyEggs() //constructor
{
Egg = new Dictionary<int, string>()
{
{ 0, "No Preference"}, //show the complete egg menu to customers
{ 1, "I hate eggs"}, //Either offer an alternative to eggs or don't show eggs on a customer personalized dynamically generated menu
//confirm with the customer if they want their eggs cooked their usual preferred way, i.e.
{ 2, "Over Easy"},
{ 3, "Sunny Side Up"},
{ 4, "Scrambled"},
{ 5, "Hard Boiled"},
{ 6, "Eggs Benedict"}
};
}
}
Теперь контроллер довольно прост, просто передавая модель. Он избегает создания изолированной концепции, которая, вероятно, не изолирована только от одной страницы.:
public ActionResult Index()
{
var model = new EzPL8.Models.MyEggs();
return View(model);
}
В представлении используется DropDownListFor (вместо DropDownList) и выражение Lambda для сильной типизации в рефакторинге событий:
@Html.DropDownListFor(m => m.Egg, new SelectList( Model.Egg, "Key", "Value"))
Voilà, полученный HTML:
<select id="Egg" name="Egg">
<option value="0">No Preference</option>
<option value="1">I hate eggs</option>
<option value="2">Over Easy</option>
<option value="3">Sunny Side Up</option>
<option value="4">Scrambled</option>
<option value="5">Hard Boiled</option>
<option value="6">Eggs Benedict</option>
</select>
Примечание. Не путайте VALUE в <option value="6">, который является ключом из словаря, из "значения" в SelectList(), который является текстом/заголовком (например, "Яйца Бенедикт" ), который заканчивается между тегами опций.
Пример использования:
Чтобы свести к минимуму трафик между приложением и базой данных, я создал статический список, чтобы избежать запроса базы данных для выпадающего списка, который редко изменяется, если он когда-либо изменяется. Тем не менее, изменения неизбежны, и через шесть месяцев умирает закусочная в моем ресторане-клиенте; не из-за зеленой ветчины, а из-за того, что у них аллергия на яйца, а повар смешался с их вафлями.
Ресторан нуждается в обновленной информации о клиентах, чтобы немедленно включить аллергии на продукты питания. В то время как они любят повторных клиентов, они не круты, когда мертвые клиенты возвращаются как зомби, у которых нет возможности платить, потому что их кредитные карты были отменены.
Риторический вопрос: Должен ли я модифицировать все контроллеры и представления, связанные с предпочтениями яйца клиента? Или просто вставьте {7, "Аллергические яйца" } в модель?
Другой риторический вопрос: не яйца омлета? Вы хотите добавить {8, "Омлет, Западный" }, {9, "Омлет, Гриб-Фета-Шпинат" } один раз к модели, и новые дополнения автоматически распространяются во всех раскрывающихся списках во всех представлениях, которые их используют
Итог (ы). Это, вероятно, больше, чем вы просили, но вы сказали MVC, а не только VC:
1. Используйте модель в * M * VC.
2. Используйте словарь в модели, когда список выбора основан только на "первичный ключ" и заголовок.
3. Если ваш статический список не работает с таблицей поиска в базе данных, ваше приложение, вероятно, не очень полезно. Когда вы добавляете опцию в статический список, более вероятно, вам также понадобится выполнить вставку в таблицу Lookup, чтобы избежать ошибки целостности отношения первичного ключа/внешнего ключа с другими таблицами в базе данных.
4. Используйте лямбда и строго типизированные структуры данных, чтобы избежать ошибок и получить поддержку типа.
