Есть ли что-то неправильное, ограничивая DataContext ViewModel окна? - PullRequest
Новая
       8

Есть ли что-то неправильное, ограничивая DataContext ViewModel окна?

2 голосов
/ 27 января 2012

Я не чувствую себя комфортно, когда какой-либо объект является DataContext моих представлений. Поскольку я следую образцу MVVM, все окна имеют свою собственную виртуальную машину. Я планирую сделать следующее (взято из окна под названием «Опции»): 

    internal new OptionsVM DataContext
    {
        get
        {
            return (OptionsVM) base.DataContext;
        }
        set
        {
            if (this.DataContext != value)
            {
                base.DataContext = value;
            }
        }
    }

Видите ли, я что-то упускаю или это может быть плохой идеей из-за того, о чем я не знаю?

Заранее спасибо.

Ответы [ 3 ]

2 голосов
/ 27 января 2012

Как правило, скрытие элементов интерфейса может привести к странным ошибкам. Например, следующий код сгенерирует InvalidCastException: 

OptionsView view = new OptionsView();
Window window = view;
window.DataContext = new DifferentVM();
OptionsVM = view.DataContext;

Это несколько надуманный пример, но если вы когда-либо используете привязки WPF для установки объекта DataContext, то подобные сценарии весьма вероятны.

Я считаю, что лучше оставить свойство DataContext таким, каким оно было разработано, и вместо этого дать моим представлениям конструктор, который принимает контекст данных более строго типизированным способом. В коде View у меня также есть свойство ViewModel соответствующего типа: 

public OptionsView(OptionsVM viewModel)
{
    DataContext = viewModel;
}

private OptionsVM ViewModel { get { return DataContext as OptionsVM; } }
2 голосов
/ 27 января 2012

Единственная проблема, которую я вижу, это то, что если вы используете конструкцию 

Window view = new OptionsView();

view.DataContext = ....;

, то DataContext все равно будет иметь тип объекта - он требует, чтобы вы всегда использовали ссылку на тип представления, чтобы увидетьтвоя сильная печать

1 голос
/ 27 января 2012

Ваш подход не должен представлять опасности - если вам будет легче, применяйте его.Просто убедитесь, что вы прокомментировали, почему вы решили реализовать это таким образом.Я за более строгую типизацию данных над базовым Object классом.Я думаю, что это на самом деле проясняет, что такое поддерживаемый контекст.

Даже использование конструкторского подхода, предложенного @SeanU, не помешает другим изменить тип DataContext после создания.

...