MVVM ViewModel должен выполнить преобразование типов / проверка?
Я работал с несколькими разработчиками за прошлые три года в относительно сложных приложениях. У нас есть кодовая база, которая использует Контролируемые исключительные ситуации довольно часто с надлежащей обработкой ошибок и некоторый другой, который не делает.
До сих пор, у меня есть он, нашел легче работать с кодовой базой с Контролируемыми исключительными ситуациями. Когда я использую чужой API, хорошо, что я вижу точно, какие состояния ошибки я могу ожидать, когда я назову код и обрабатываю их правильно, или путем входа, отображения или игнорирования (Да, существуют допустимые случаи для игнорирования исключений, таких как реализация ClassLoder). Это дает код, который я пишу возможности восстановиться. Все исключения на этапе выполнения, вплоть до которых я распространяю, они кэшируются и обрабатываются с некоторым универсальным кодом обработки ошибок. Когда я нахожу контролируемую исключительную ситуацию, которую я действительно не хочу обрабатывать на определенном уровне, или что я рассматриваю ошибку логики программирования, тогда я обертываю его в RuntimeException и позволяю ему пузырь. Никогда не глотайте исключение без серьезного основания (и серьезные основания для того, чтобы сделать, это довольно недостаточно)
, Когда я работаю с кодовой базой, которая не имеет контролируемых исключительных ситуаций, она делает это мне немного тяжелее для знания перед рукой, что может я ожидать при вызывании функции, которая может повредить некоторый материал ужасно.
Это - все, конечно, вопрос навыка разработчика и предпочтения. Оба способа запрограммировать и обработка ошибок могут быть одинаково эффективными (или непригодными), таким образом, я не сказал бы, что существует Один Путь.
, В целом, я нахожу легче работать с Контролируемыми исключительными ситуациями, особенно в крупных проектах с партией разработчиков.
4 ответа
Это очень интересный вопрос, и я не думаю, что на него есть однозначный ответ, но я сделаю все возможное, чтобы высказать свои мысли.
Глядя на MVVM. Насколько я понимаю, цель ViewModel - предоставить данные таким образом, чтобы представление могло их понять без каких-либо предположений о том, как представление будет их использовать. В качестве примера представим, что мы моделируем скорость автомобиля:
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. Приняв идею о том, что данные являются int, View может использовать текстовое поле или какой-либо другой элемент управления, который принимает только числа (например, циферблат) для отображения информации. Если мы говорим, что собираемся форматировать данные так, как мы полагаем, полезны для представления, это лишает его этой важной силы.
С другой стороны, мы работаем в реальном мире. Мы стремимся знать, что такое точка зрения. Мы редко подключаем и воспроизводим разные представления поверх одной и той же ViewModel, и добавить код преобразования в ViewModel просто проще. Я не думаю, что это правильно, но это не значит, что вы не найдете мой производственный код, использующий его ...
Наконец (и я уверен, что вы это знаете, но для полноты картины ...) бизнес-логика должна выполняться в ViewModel. Если мы решим, что машина не должна Если вы не превышаете 70 миль в час, то это не обязанность обзора. Таким образом, вы все равно получите своего рода провайдер ошибок, но на уровне бизнеса, а не на уровне отображения.
Ладно, может быть, это и не было окончательно ....
Я хотел ответить на комментарии, сделанные Кентом, и мои мысли не укладывались в комментарий.
Очевидно, основное различие между моими и Кентом. точки зрения (насколько я понимаю) он читает ViewModel как модель представления, а я прочитал это как то, что представляет модель для представления. Я допускаю небольшую разницу, но я думаю, что в результате я не хочу удалять информацию, которую предоставляет модель, даже если это упрощает работу с конкретным видом, который я использую.
Моя точка зрения основан на предположении, что вы должны иметь возможность менять просмотры, они должны быть мимолетными, которые могут меняться в зависимости от требований к размеру экрана, оборудованию, платформе, задержке и среде. Интересный поворот состоит в том, что я никогда не нуждался в этой функциональности, и я не видел ничего (помимо доказательства концептуальных приложений), которые когда-либо использовали бы ее, но если мы примем, что мы не будем использовать ее сейчас или когда-либо точка в будущем, и что каждая ViewModel будет работать с одним и только одним View, тогда мы можем также вернуться к помещению всего кода в файл кода программной части и полностью выбросить ViewModel - в конце концов, это так тесно в сочетании с тем, что это может быть один и тот же класс.
В идеале я бы хотел, чтобы модель ViewModel могла сказать: «это значение - int, оно всегда будет int, и вы можете отображать его как угодно.
Absolutely it belongs in the view model, for all the usual reasons, including:
- Designers own the XAML. Do you want the designers to have to understand and implement the requisite type conversion and validation logic?
- Testability. Don't you want to validate that your conversion and validation logic is working correctly? It's much harder if it's embedded in the view.
On the other hand, conversion, validation etc. will be less declarative, explicit and flexible, from the point of view of the View designer
I think this is a moot point because the view designer should be responsible for these things. The designer is trying to make the UI look and feel a certain way; it is the developer who implements the business logic, including conversion and validation logic.
Это хороший вопрос, и я, безусловно, вижу обе стороны обсуждения.
Я считаю, что вы действительно ищете правильный NumericInputControl , который вы можете использовать в своем xaml. Это обеспечит лучший пользовательский опыт, потому что ваши пользователи не смогут случайно ввести текст в числовое поле и, поскольку элемент управления ограничивает ввод без его проверки, вы можете поддерживать более строго типизированную ViewModel.
Я не знаю, как бы вы хотели его реализовать, я знаю, что классические элементы управления spinner / NumericUpDown теряют популярность, потому что они не удобны для сенсорного ввода, но я не верю, что введение такого элемента управления нарушают чистоту дизайнерского подхода или ваших ViewModels. Вы' Я получу число, которое затем можно будет проверить в соответствующем месте, предоставить обратную связь через IDataErrorInfo , как обычно, и так далее. :) Этот метод позволяет вам получить лучшее из обоих миров без каких-либо реальных недостатков (кроме создания числового элемента управления).
Должна ли MVVM ViewModel выполнять тип преобразование / проверка?
Да .
Модель представления - это уровень абстракции между представлением и моделью - идеальное место для выполнения преобразований любых типов (вместо громоздких преобразователей значений). Проверка должна обязательно происходить как часть модели представления.
Мы используем нашу модель представления для обработки преобразований в максимально возможной степени для типов данных. Это снижает потребность в преобразователе значений в некоторых очень специфических обстоятельствах. Вы хотите предоставить любой тип, который проще всего использовать в представлении. Это работает хорошо.
Один конкретный вопрос, который вы подняли:
Если, скажем, нечисловое значение вводится в текстовое поле, привязанное к числовое свойство, преобразование терпит неудачу, свойство никогда не устанавливается, и у нас никогда не будет возможности предоставить правильная обратная связь с пользователем. Хуже, собственность сохраняет свой текущий значение, что приводит к несоответствию между что отображается в представлении и то, что на самом деле находится в ViewModel.
, можно обработать, выставив ваш тип модели представления как обнуляемый тип . Это должно по-прежнему позволять обновлять базовый источник, даже если введены недопустимые данные, и запускать проверку. Это работало в аналогичной ситуации, которая была у нас с DateTime и средством выбора даты и времени.
Сохраняйте представление как тупое. У нас нет официальных дизайнеров, наши разработчики являются нашими дизайнерами, поэтому сохранение представления в тупике дает некоторые преимущества:
- Мы (разработчики) должны сохранять здравомыслие (XAML несколько менее подробный)
- Бизнес-логика (включая проверку ) остается в модели представления и может включать тестирование
Удачи!
-Z