Делай или не делай.Valueconverters в MVVM - PullRequest
2 голосов
/ 14 июня 2011

Я ищу либо подтверждение / подтверждение того, что то, что я делаю, следует образцу и является наилучшей практикой, либо кого-то, кто оскорбляет меня в слове!

Если я делаю привязку видимости [вставить элемент управления здесь], я привязываю ее к свойству типа System.Windows.Visibility.Затем я устанавливаю значение Visible / Collapsed в зависимости от бизнес-логики.Один потенциальный недостаток в этом заключается в том, что мое свойство VM теперь напрямую связано с типом, который я мог видеть абстрагированным в преобразователь значений.С учетом сказанного я часто читал в обсуждениях MVVM, что ValueConverters не следует использовать.

Могу ли я получить отзыв об этом, пожалуйста?

Спасибо!

SS

Ответы [ 4 ]

4 голосов
/ 14 июня 2011

Я думаю, что вполне нормально использовать преобразователи значений для распространенных сценариев пользовательского интерфейса (например, привязка видимости к логическому свойству). Однако используйте их только для задач, связанных исключительно с пользовательским интерфейсом: не помещайте бизнес-логику в конвертер, он там не принадлежит.

1 голос
/ 14 июня 2011

Представление (XAML / WPF) и ViewModel отвечают за разные вещи. Поэтому, если вы манипулируете данными, которые обслуживает ViewModel, вероятно, лучше всего выполнить преобразование в ViewModel. Однако, если вам нужно преобразование только для элемента пользовательского интерфейса, тогда представление является лучшим местом для него.

например. Я бы сказал, что видимость является обязанностью ViewModel, поскольку, вероятно, существуют некоторые бизнес-правила относительно того, что отображается. Однако, когда вы меняете множественное число метки, вероятно, ответственность за пользовательский интерфейс. Кроме того, вы можете решить использовать триггеры, а не конвертеры. Это не должно беспокоить ViewModel.

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

1 голос
/ 14 июня 2011

Это спорная тема, но я сижу в лагере, где я думаю, что вы не должны использовать конвертеры. ViewModel считается «Конвертером на стероидах», поэтому вам не нужны конвертеры. (http://groups.google.com/group/wpf-disciples/browse_thread/thread/3fe270cd107f184f?pli=1)

Если вы используете конвертеры, вы обнаружите, что они оказываются повсюду в вашем проекте для самых простых вещей. Пример: хотите отобразить «3 клиента», но не иметь множественного числа, если это «1 клиент». Это легко сделать в ViewModel, но в конвертере очень быстро и утомительно.

0 голосов
/ 14 июня 2011

Я фанат Конвертеров, но специально для повторного использования. Это может быть легко сделать эти преобразования в ViewModel, но что, если вы хотите одно и то же преобразование во многих ViewModel или даже в 15 различных приложениях? Если вы ограничитесь только подходом ViewModel, вы нарушите DRY. При этом я не могу согласиться с тем, что конвертеры не должны содержать бизнес-логику и не должны использоваться для одноразовых решений.

В случае, о котором вы упомянули выше, для вашей модели будет требоваться свойство типа Visibility, которое для меня является запахом кода. ИМХО, ViewModels не должны отражать визуальное состояние, скорее визуальное состояние View должно реагировать на состояние данных ViewModel.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...