Здравствуйте, скажите пожалуйста зачем и в чём удобства Converter
'а в Binding
'е?
Конвертеры нужны, чтобы не выносить в VM логику представления. VM, например, не должна хотеть знать ширину колонки таблицы, текущий язык, выбранный скин приложения и тому подобные чисто вьюшные подробности. Вот для перевода VM-объектов во вьюшный вид и нужны конвертеры.
Примеры.
У вас есть VM-объект, означающий дату. Его тип, понятно, DateTime
. А в UI вы хотите показывать его в виде «сегодня», «вчера», «неделю назад», «1 апреля» или как-то ещё. Перевод в такую нотацию — хорошее место для конвертера.
Вам нужно вывести «15 экземпляров», но если колонка слишком узкая, то нужно сократить текст до «15 экз.». Заниматься размерами колонок — не дело VM, напишите для этого конвертер.
В VM у вас язык сообщения, а во View вы решили показывать его в виде флажка нужной страны. Конвертация CultureInfo
в pack URI к вашему графическому ресурсу — не задача VM, оставьте это конвертеру. VM вообще не знает ничего о графических ресурсах.
В VM некоторые данные иногда отсутствуют (значение свойства равно null
), и вы не хотите показывать рамку с красивым фоном для пустых данных. Превратить null
в Visibility.Collapsed
— конвертер и только он.
У вас есть клетка игровой доски, и вам нужно выяснить её координаты. (Предположим, что ваши клетки не квадратные, и в грид автоматически не укладываются.) Размер клетки зависит от размера окна, количества клеток и ещё каких-то чисто визуальных подробностей. Кто будет пересчитывать координаты? VM? Фигушки, эту задачу должен решать конвертер.
У вас есть кастомный прогрессбар, он не линейный, а круглый. Кто-то должен пересчитать положение прогрессбара в угол. VM? Нет, VM ничего не знает о стиле, который вы дали прогрессбару. А выставлять свойства для круглого, квадратного и семиугольного прогрессбаров совсем несемантично. Поэтому пусть стиль прогрессбара пользуется конвертером.
Вам нужно привязать ширину одного контрола, чтобы она равнялась удвоенной ширине другого контрола. Кто будет умножать на два? Выносить задачу в VM через 18 привязок? Просто добавьте конвертер.
В общем, для конвертеров найдётся много задач чисто визуального характера.
Простой вариант - действительно делать все нужные свойства в VM
и просто биндиться на них во View
.
Пока вас это устраивает, конвертер вам не нужен.
С другой стороны, очень часто надо работать с чем-нибудь, для чего например есть стандартные входные данные и стандартное отображение.
Как пример - Markdown
разметка, у которой есть вполне себе стандарты написания, но выводить голым текстом такое неудобно, поэтому вполне пригодится конвертер из Markdown
в FlowDocument
.
Другая ситуация, когда конвертер часто пригождается - изображения. Основной способ хранения и передачи бинарных данных - массив байт, увидеть его в VM
- вполне нормальная ситуация. Соотвественно, для отображения потребуется конвертер, который например заточен на определенный формат изображений, размеры или ещё какие то настройки.
Ещё всегда можно использовать конвертеры не совсем по назначению. Встречал такое редко, но тем не менее. Например, для ввода условного номера телефона по маске - хранить и передавать номер будет в виде цифр исключительно, а отображаться в каком нибудь типа +8(999)123-34-56.
Айфон мало держит заряд, разбираемся с проблемой вместе с AppLab
Перевод документов на английский язык: Важность и ключевые аспекты
У меня есть SVG, который содержит электрическую схемуИспользуя Xamarin я вывел схему на экран
У меня есть родительский компонент и набор дочерних функциональных компонентов, refs на которые, я храню в массиве state родителяВ определенный...
есть функция которая обрабатывается через клик в textarea, как сделать такую же на на кнопку? {{STORY_ID}} - это id поста к которому привязан textarea , а {{PUBLISHER_ID}}...