Повышение производительности при использовании конвертера будет незначительным.Однако выбор следует основывать на том, где вы реализуете свойство.
Свойство Visibility имеет смысл только для класса на уровне пользовательского интерфейса (пользовательский элемент управления или, возможно, модель представления).Если вы создаете свойство для класса модели, который просто используется для управления вашим пользовательским интерфейсом в этом случае, было бы более целесообразно использовать логическое значение и преобразователь.
РЕДАКТИРОВАТЬ: добавлен (слегка надуманный) пример
Например, представьте, что у вас есть класс данных (модель) для редактируемого объекта с именем Foo, и Foo может быть "простым" или«расширенный».«Расширенный» Foo отобразит дополнительные элементы редактирования в пользовательском интерфейсе, поэтому нам нужно привязать свойство Visibility панели расширенного редактирования к некоторому свойству.
Ваш класс Foo может иметь свойствочтобы указать, продвинутый он или нет.Это свойство должно определенно быть логическим - НЕ Visibility - потому что ваш класс Foo не должен заботиться о каких-либо особенностях пользовательского интерфейса, который его отображает.Таким образом, логическое Foo.IsAdvanced будет подходящим свойством.
В этом случае вы можете напрямую связать с Foo.IsAdvanced и использовать конвертер.То, что вы определенно не хотите сделать, - это создать Visibility свойство Foo.AdvancedEditControlVisibility, поскольку Foo должен быть внутренним классом данных.
Если вы хотитеСоздайте свойство, которое не требует конвертера, вы должны создать это свойство в более высоком классе, специфичном для вашего пользовательского интерфейса.Некоторые архитектурные паттерны называют этот класс «ViewModel» - это класс, который представляет модель таким образом, чтобы данные лучше подходили для отображения в пользовательском интерфейсе.Таким образом, вы можете создать класс, который принимает Foo и предоставляет свойство AdvancedEditControlVisibility, которое основано на значении его Foo.IsAdvanced.
В этом случае вы можетепривязка непосредственно к свойству на модели представления без конвертера.Обратите внимание, что в конечном итоге вы все равно сделали преобразование - вы просто сделали его более явной частью своего кода, вместо того, чтобы ограничиваться разметкой.
Мысленный процесс заключается в том, что модель представления является "более высокой"level "class - класс, который оборачивает ваш класс данных и включает в себя логику, специфичную для пользовательского интерфейса, и поэтому более уместно включать код, специфичный для вашего пользовательского интерфейса.В идеале вы должны взять каждый класс вашего проекта по очереди и убедиться, что он имеет определенную цель: если Foo является бизнес-объектом, который содержит данные, почему он должен предоставлять (или даже заботиться о!) Видимость некоторыхчасть интерфейса используется для его отображения?Что произойдет, если вы добавите Foo в приложение командной строки или веб-приложение?Если в бизнес-классе у вас есть специфичная для WPF-UI логика, значит, ваша инкапсуляция неправильная, но иногда такое разделение проблем - одна из самых сложных вещей, которую нужно исправить.
И с точки зрения производительности вызаметить небольшую разницу: -)