Separating views, command presentation (Text, Icon) and command logic (Execute, CanExecute)

Question

If TL;DR: see the last paragraph.

Pure WPF "suggests" putting presentation (controls, text, icons) into views and command logic (Execute, CanExecute methods) into code-behind. Besides putting logic both into views (CommandBindings) and code-behind being a frowned upon practice, it doesn't help at all with XAML duplication: text, icons, large icons, hints, and numerous other properties have to be duplicated every time a command is used: for main menu, for context menu, for toolbar button, for ribbon button and other controls.

Looks like the first problem (truly separating views and logic) is solved by DelegateCommand, RelayCommand and approaches like that. Command logic is moved into ViewModels (or Controllers in case of MVVMC), code-behind is clean, no CommandBindings and other nonsense in views.

However, I can't find a commonly accepted solution to the presentation duplication problem. I want to separate command presentation (text, icons) and command logic (Execute, CanExecute methods). All code I could find either puts presentation into code (by creating a RoutedCommand with additional properties like Label and Icon), or puts code into presentation (that is, handlers into views and code-behind). I don't like either. I think presentation should be completely in XAML, and code should be completely in CS (either in ViewModel or Controller).

Question: how to separate views (XAML with controls which reference commands), presentation of commands (labels, icons etc. for every command) and logic of commands (C# code for Execute, CanExecute etc. in ViewModels or Controllers)?

Idealize

Two close votes already? And zero comments? Is the question unasnwerable or did I miss something? If you vote to close, leave a comment at least, please. I can't learn if you don't tell me what I did wrong. – Idealize

Read the "non constructive" description on the FAQ - "this question will likely solicit debate, arguments, polling, or extended discussion". By that same token, Stack Overflow is not a good place to ask "how should I build my software?" questions. – Angio

@JeanHominal The way I see it, I haven't asked how to build MY software, I've asked about a problem I think is very common, considering how much code I've seen where this problem isn't solved, even in Microsoft's code. And judging by votes (5 +1 votes from 20 views), I'm not the only one who wants to find a solution. – Idealize

I really should have kept only the first sentence of my previous comment. I meant that it is likely that any answer will result in debate. (A lot of "patterns" questions result in that) – Angio

Answer 1

There is no built-in solution to this problem, your're going to have to roll-up your sleeves and create the required structure yourself.

In a recent project I worked on, I did exactly this. I created a concept called an 'action' which supplements the WPF ICommand with other visual properties. It was something like this ...

interface IAction
{
  ICommand Command { get; }
  string DisplayText { get; }
  string ToolTipText{ get; }
  URI Icon { get; }
}

The application contained a collection of Action instances. These could then be bound to menus, toolbars etc ... allowing the same Action instance to be re-used with various different presentation styles. It is all fairly straightforward MVVM stuff!

Betweenwhiles