Обычный способ избежать кодирования позади команд - это избегать RoutedCommands. В различных вариациях темы MVVM (Model-View-ViewModel) люди склонны использовать пользовательские реализации ICommand. Они пишут класс ViewModel, который помещается в DataContext пользовательского интерфейса. Эта ViewModel предоставляет свойства типа ICommand, и эти свойства команды связаны с элементами меню, кнопками и т. Д. Через привязку данных. (И обычно это всего лишь одна реализация ICommand, используемая снова и снова - ищите в Интернете либо RelayCommand, либо DelegateCommand, либо DelegatingCommand, и вы увидите шаблон - это в основном ICommand как оболочка для делегата с необязательной поддержкой включенного /disabled.)
В этой идиоме вы почти никогда не используете встроенные команды, такие как ApplicationCommands.Open. Единственное реальное использование для этих вещей, если вы хотите, чтобы чувствительные к фокусу команды обрабатывались внутренне средствами управления. Например, TextBox имеет встроенную обработку команд для редактирования, копирования, вставки и т. Д. Это позволяет избежать проблемы codebehind, поскольку это полностью настраиваемый элемент управления, а настраиваемые элементы управления на самом деле не имеют codebehind как таковые - все они являются кодом. (На самом деле Xaml находится в совершенно отдельном объекте, шаблоне, и на самом деле не является частью элемента управления.) И в любом случае, это не ваш код - у вас есть элемент управления, который уже знает, как поддерживать команду, поэтому вы здесь можно целиком и полностью оставаться в пределах Xaml.
Командная маршрутизация интересна в этом конкретном сценарии, поскольку она позволяет вам поместить один набор элементов меню, связанных с различными элементами управления редактированием, и система маршрутизации выясняет, какое текстовое поле (или что-то еще) будет обрабатывать команду, основываясь на том, где находится фокус , Если это не то, что вам нужно, командная маршрутизация, вероятно, не слишком полезна для вас.
Однако здесь возникает большая проблема, что делать, когда вы обнаружите, что вам действительно нужно поместить код в коде позади. Команды обычно не являются примером этого сценария, если вы используете пользовательские реализации ICommand (хотя есть странное исключение), но есть несколько более интересные события пользовательского ввода. Вы упоминаете двойной щелчок, но также, если вы делаете какую-то необычную интерактивность, вам, как правило, нужны такие вещи, как мышь вверх / вниз и т.д.
В этом случае обычный подход состоит в том, чтобы откусить маркер и поместить код в коде, но вы пытаетесь сохранить его на одной строке для каждого обработчика события. По сути, ваш код позади просто вызывает соответствующий метод в модели представления, и это то, что действительно обрабатывает событие.
Приятно то, что это действительно облегчает написание автоматизированных тестов. Хотите смоделировать ввод мыши в определенную часть вашего интерфейса? Нет необходимости возиться с инфраструктурой автоматизации пользовательского интерфейса модульного тестирования - просто вызовите соответствующий метод напрямую!