Ваш подход совершенно верен (хотя я бы использовал мультисвязывание для второго примера, а не такой специализированный конвертер), хотя, помещая всю свою логику в XAML, вы создаете очень высокую связь между тем, как выглядит приложение и как он себя ведет, из-за этого вы можете захотеть взглянуть на шаблон MVVM, чтобы отделить эти вещи.
По шаблону MVVM ваш XAML (представление) просто содержит очень простые привязки данных в ViewModel, которая обрабатывает всю логику и обновляет представление через интерфейс INotifyPropertyChanged. Код для вашего третьего примера может выглядеть примерно так:
public class DirectoryManagerViewModel : INotifyPropertyChanged
{
private string _directory;
public string Directory
{
get { reutrn _directory; }
set
{
if (_directory != value)
{
_directory = value;
OnPropertyChanged("Directory");
if (IsValidDirectory(value))
{
PopulateFiles();
}
}
}
}
public ObservableCollection<FileViewModel> Files { get; private set; }
private bool IsValidDirectory(string directory)
{
//return if the directory exists etc.
}
private bool PopulateFiles()
{
//Populate Files with files in directory
}
}
Где FileViewModel - другая модель представления, которая содержит имя и значок для файла.
Преимущество этого подхода состоит в том, что ViewModels можно повторно использовать с другими представлениями и другими технологиями, такими как ASP.NET или Winforms, чтобы вы не были заблокированы в стеке WPF. (Если вы работаете в среде, где есть дизайнеры, отвечающие за внешний вид, и разработчики, отвечающие за поведение, это помогает определить эти границы)
В конце концов, хотя эта логика и должна куда-то идти, и хотя есть лучшие и худшие способы для разработки вашего приложения, вы все равно будете писать код, который принимает строку и преобразует ее в серию имен файлов и иконки где-то.