Это распространенная проблема, которая возникает у многих людей, и существует действительно «простой» способ заставить ее работать.Однако, если вы планируете, чтобы это приложение росло или было значительно сложнее, простой выход из строя нанесет вам вред.Большинство других ответов расскажут вам о легком пути. Давайте хотя бы обсудим правильный путь .
Во-первых, давайте проясним отношения между главной страницей и страницей с контентом.Страница содержимого не должна напрямую вызывать элементы, специфичные для реализации, на своем главном или наоборот.Они разделены контрактом Page-Master.Что происходит на логическом уровне?Что-то происходит на странице содержимого, что должно привести к отключению определенной кнопки.
Теперь, поскольку кнопка находится на главной странице, она не должна знать о конкретная страница содержания.Таким образом, кнопка также не должна отвечать за вызов экземпляра страницы и проверять критерии, а также не должна явно подписываться на событие определенного типа.
Так что же делать?Должен существовать некоторый объект основных данных (возможно, одноэлементный), который будет находиться в централизованно доступном месте в течение всего времени существования запроса.Скажите, HttpContext.Items или Session.Будучи объектом основных данных, это должен быть единый орган для управления этими условиями, о которых вы говорите.Он должен вызывать событие, когда какая-либо из данных изменяется, и любой (например, ваша кнопка) может подписаться на это событие и принимать решения на основе состояния.(Пример ниже)
Если ваше приложение будет глупо-простым, то это определенно излишне.Но по мере того, как вы становитесь разработчиком и начинаете создавать более сложные системы, вам необходимо помнить об этих вещах, чтобы сделать ваши приложения проще, стабильнее и удобнее в обслуживании.
Вот два конкретных, реальныхМир вещей, к которым обращается этот подход, которые приходят из моего опыта.
Это довольно просто - если вам нужно поменять мастер-страницы во время выполнения, вы хотите полностью отделить реализацию вашей страницы и мастер-страницы.На одной главной странице могут быть вещи, которых нет на другой.Один мой конкретный случай немного экстремален - у нас есть десятки мастер-страниц, вложенных до 6 слоев глубиной, которые меняются местами во время выполнения.Но принцип гибкости остается тем же - посмотрите, сколько вопросов есть на этом сайте, чтобы узнать, как изменить мастер-страницу во время выполнения!
Этот вопрос немного сложнее, но все еще имееточень практичные последствия.Разделение логических обязанностей на отдельные классы имеет один очень важный эффект - обычно оно уменьшает общее количество логических ветвей (например, if операторов) в ваших приложениях.Это самый большой источник ошибок.Если у класса нет никакой логики, для него довольно сложно иметь ошибки!:) Когда вы начинаете думать о приложениях с точки зрения человеко-лет и времени разработки и измерять сотни тысяч или миллионы строк кода - меньшее количество логических ветвей, агрегированных по всему приложению, реально измеримо влияет на стабильностьи изменчивость.Обслуживание и усовершенствования в большей степени сводятся к организации простых и стабильных компонентов, чем к выполнению операций с кодом.
Вот пример класса мастер-данных:
public class MasterData
{
private string _state1;
public string State1
{
get { return _state1; }
set
{
_state1 = value;
OnDataChanged();
}
}
private string _state2;
public string State2
{
get { return _state2; }
set
{
_state2 = value;
OnDataChanged();
}
}
public event EventHandler DataChanged;
private void OnDataChanged()
{
if(this.DataChanged != null)
{
OnDataChanged(this, EventArgs.Empty);
}
}
}