MVVM: объект VM должен выставить объект M непосредственно, или только посредством делегирования методов считывания к методам считывания M?
Можно использовать 0$ для определения названия сценария (с полным путем) - для получения названия сценария только можно обрезать ту переменную с
basename $0
3 ответа
Модель представления должна объявлять свои собственные свойства и скрывать особенности модели от представления. Это дает вам максимальную гибкость и помогает предотвратить просачивание проблем типа модели в классы модели. Обычно классы модели представления инкапсулируют модель путем делегирования. Например,
class PersonModel {
public string Name { get; set; }
}
class PersonViewModel {
private PersonModel Person { get; set;}
public string Name { get { return this.Person.Name; } }
public bool IsSelected { get; set; } // example of state exposed by view model
public PersonViewModel(PersonModel person) {
this.Person = person;
}
}
Помните: модель не должна ничего знать о модели представления, которая ее использует, а модель представления ничего не должна знать о представлении, которое ее использует. Вид не должен ничего знать о моделях, скрывающихся на заднем плане. Таким образом, инкапсулируйте модель за свойствами в модели представления.
По этому вопросу нет единого мнения. Например, это был один из открытых вопросов о MVVM, сформулированный Уордом Беллом здесь :
Разрешено ли виртуальной машине предлагать V и развернутый M-объект (например, необработанный Сотрудник) ? Или М-объект должен свойства (если это даже разрешено иметь свойства!) быть выставленным исключительно через поверхность Обертка виртуальной машины?
Основные преимущества отказа от прямого отображения модели в виртуальной машине:
вы можете использовать ее как «преобразователь на стероидах», формируя значения модели удобным для вас способом
может внедрять другие функции, связанные с пользовательским интерфейсом, например сообщения проверки данных , отменить повтор , ..
Минусы:
вам придется дублировать много код для отображения всех свойств модели в модели просмотра.
если вы привяжете элемент управления представлением к свойству viewmodels, вы отправите события propertyChanged из модели просмотра. Но что произойдет, если свойство модели изменится из другого источника, отличного от установщика модели представления? Затем он должен уведомить модель просмотра, чтобы вы закончили с двумя OnPropertyChanged, одним в модели и одним в модели просмотра ... довольно сложно!
Наличие ViewModel для любой модели могло быть хуже. Что, если у вас есть иерархическая структура модели или даже простая коллекция? В этом случае вам придется перебирать все модели и создавать экземпляр ViewModel для каждой модели, а также регистрировать уведомление об изменении события или другие события. ИМХО, это совершенно безумие и неразумно. Как сказал DaniCE, вы получите много кода и большую головную боль.