MVVM - привязка напрямую к объекту модели, предоставляемому из виртуальной машины, или реализация отдельного свойства в виртуальной машине для доступа к свойствам модели

Question

Извините, если название сбивает с толку, но я не знаю, как сократить мой вопрос. Во всяком случае, здесь это идет.

Я использую WPF, Entity Framework и MVVM.

В настоящее время в моей ViewModel есть свойство

public Model.Document Document {get;set;} //Model.Document is an EF Entity

Затем в XAML я связываюсь с

<TextBox Text={Binding Path=Document.Title}/>

Заголовок - это, конечно, свойство модели.

Теперь у меня возник следующий вопрос: Чтобы отделить Модель от Представления, не было бы лучше, если бы я добавил свойство в ViewModel, например

    public string Title
    {
        get { return Document.Title; }
        set { Document.Title = value; }
    }

, а затем связать так:

<TextBox Text={Binding Path=Title}/>

Какой способ рекомендуется?

Answer 1

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

Реализует ли Model.Document интерфейс INotifyPropertyChanged ? Если нет, я бы порекомендовал добавить свойство Title к вашей модели представления и реализовать INotifyPropertyChanged в вашей модели представления, чтобы при изменении заголовка возникало событие PropertyChanged , чтобы уведомить представление.

Другим подходом было бы представить заголовок модели представления как DependencyProperty , поскольку время привязки и рендеринга быстрее.

Answer 2

Вы можете взглянуть на BookLibrary пример приложения WPF Application Framework (WAF) . Он использует первый подход и по-прежнему следует паттерну MVVM (разделение задач, проверка на единицу).

Это упрощает ViewModels, потому что Binding использует реализацию Entities INotifyPropertyChanged . В противном случае вам придется синхронизировать изменения вручную между ViewModels.

Answer 3

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

Предоставляя свойство Document, вам не нужно дублировать все свойства, к которым вам нужно получить доступ. Поэтому, если у вас есть множество свойств или вы используете какое-то отражение (например, отображение Document в PropertyGrid), то этот способ, вероятно, лучше.

Последний подход дает вам больший контроль над значением, отображаемым в представлении. Таким образом, вы можете изменить заголовок (то есть удалить лишние пробелы), прежде чем он будет зафиксирован в модели или других действиях. Вы даже можете обменяться с документом, даже если View не знает об этом (или даже не заботится).

Answer 4

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

Вот простой пример .

Answer 5

Я не вижу проблем с привязками только для чтения к свойствам модели, значения которых не меняются.

Это две действительно важные квалификации. Привязка чтения / записи к свойствам модели настолько чревата потенциальной проблемой, что вместо того, чтобы трезво анализировать ситуацию, чтобы увидеть, не является ли это одним из случаев, в котором ее нет, я бы просто внедрил свойство в модель представления и сделал с этим. И если моя модель не поддерживает уведомление об изменениях, если мне это нужно, что я, вероятно, и делаю, мне потребуется реализовать его в модели представления.