Это очень интересный вопрос, и я не думаю, что на него есть однозначный ответ, но я сделаю все возможное, чтобы высказать свои мысли.
Глядя на шаблон MVVM, как я его понимаю, смысл ViewModel состоит в том, чтобы представить данные так, как View может понять без каких-либо предположений о том, как представление будет использовать его. Для примера давайте представим, что мы моделируем скорость автомобиля:
public class CarModel
{
public int MilesPerHour { get; set; }
}
public class CarViewModel
{
private CarModel _model;
public int MilesPerHour
{
get { return _model.MilesPerHour; }
set { _model.MilesPerHour = value; }
}
}
В приведенном выше примере я выставил свойство как int, поскольку оно есть в модели. Недостатки этого вы перечислили в своем вопросе, но главное преимущество заключается в том, что он дает создателю представления ценную информацию о том, как отображать эти данные. Помните, что мы (как авторы ViewModel) не знаем, как выглядит View. Приняв идею о том, что данные являются целыми, представление может использовать текстовое поле или какой-либо другой элемент управления, который принимает только цифры (например, циферблат) для отображения информации. Если мы говорим, что собираемся отформатировать данные таким образом, чтобы мы предположили, что полезен для просмотра, это отнимает у него эту важную силу.
С другой стороны, мы работаем в реальном мире. Мы склонны знать, что это за точка зрения. Мы редко подключаем и воспроизводим разные представления поверх одной и той же ViewModel, и просто добавить код преобразования в ViewModel. Я не думаю, что это правильно, но это не значит, что вы не найдете мой производственный код, использующий его ...
Наконец (и я уверен, что вы это знаете, но для завершения ...) бизнес-логика должна быть выполнена во ViewModel. Если мы решим, что автомобиль не должен превышать 70 миль в час, то ответственность за это не возлагается на точку зрения. Таким образом, у вас все равно останется какой-то поставщик ошибок, но на уровне бизнеса, а не на уровне отображения.
Хорошо, может быть, это не было окончательно ...
Я хотел ответить на комментарии Кента, и мои мысли не вписались в комментарий.
Очевидно, что основное различие между моей точкой зрения и точкой зрения Кента (насколько я понимаю) состоит в том, что он читает ViewModel как модель представления, а я читаю это как то, что выставляет модель представлению. Я допускаю небольшую разницу, но я думаю, что в результате я не хочу удалять информацию, предоставляемую моделью, даже если это облегчает конкретное представление, которое я использую.
Моя точка зрения основана на предположении, что вы должны иметь возможность менять представления, они должны быть мимолетными, которые могут меняться в зависимости от требований к размеру экрана, аппаратному обеспечению, платформе, задержке и среде. Интересным моментом является то, что мне никогда на самом деле не нужна была эта функциональность, и я не видел ничего (кроме доказательства концептуальных приложений), которое когда-либо использовало ее, но если мы примем, что мы не будем использовать ее сейчас или в любой момент указать на будущее, и что каждая ViewModel будет работать с одним и только одним View, тогда мы можем также вернуться к размещению всего кода в файле code-behind и полностью выбросить ViewModel - в конце концов, это так тесно в сочетании, что это может быть тот же класс.
В идеале мне хотелось бы, чтобы ViewModel могла сказать: «это значение является целым числом, оно всегда будет целым числом, и вы можете отобразить его любым способом, который вам нравится. Но вы можете отдать мне все, что угодно, и я» Я сделаю все возможное, чтобы сделать его подходящим, и если я не смогу, я дам вам знать ". По сути, в моем свойстве MilesPerHour должен быть объект int get, но объект set. Таким образом, представления хранят всю информацию, которая, по моему мнению, им нужна, но не нужно беспокоиться о конверсиях или проверке.