Следующий код будет работать независимо от типа элемента с привязкой к данным и свойства отображаемого элемента:
var isValid = cmbo.Items.Cast<Object>().Any(x=>cmbo.GetItemText(x) == ddPerson.Text);
Я соглашаюсь с AviewAview, но только выдал бы исключения, если пользователь говорит (не, если он спрашивает):
public Foo
{
bool Validate(Baz bar)
{
if(!is_number(bar)) return false;
return true;
}
AssignBar(Baz bar)
{
if (!Validate(bar)) throw numberexception();
}
}
Скажите:
try
{
foo.AssignBar(bar);
}
catch(numberexception e)
{
alert('Not a number!');
}
Спросите:
if (foo.Validate(bar)
{
foo.AssignBar(bar);
}
else
{
alert('Not a number!');
}
Таким образом, AssignBar ожидает ДОПУСТИМУЮ панель и выдает исключение, если это не будет, но мы также предоставляем метод для Проверки, который не выдает исключение.
Интересно, является ли это больше проблемой "разделения проблем", чем, "говорят, не спрашивают". Чья ответственность это должно проверить данные? Возможно, это - вещь, ответственная за сохранение его.
Конечно, иногда полезно проверить данные в нескольких слоях. Если это верно, для Вашего приложения, у меня нет проблемы с представлением логики проверки в "пользовательском" слое. Но я все еще хотел бы это в бизнес-слое.
Я думал, что это походило на загрузку "Лучших практик" и пошедших не так, как надо "Методологий проектирования", но теперь это отчасти имеет смысл мне. Посмотрите на него этот путь:
Предположите помещать проверку в Бизнес-объект, но, "что я делаю если сбои проверки на уровне представления. Это позволило бы нескольким различным уровням представления снова использовать ту же логику проверки, но обрабатывать ошибки по-другому.
public Foo { Validate(Baz bar) { if(!is_number(bar)) throw numberexception(); } AssignBar(Baz bar) { Validate(bar); } } //... try { foo.AssignBar(bar); } catch(numberexception e) { alert('Not a number!'); }
n.b. можно обсудить все, которое Вы хотите о выдавании исключения, оно было предназначено как пример. Возвратите состояния, bools, независимо от того, что Вы хотите.