17

I try to avoid code behind in views, within my WPF MVVM project.

However I have some things that are very specific to the view. For example when a control gets focus I want the full text to be highlighted (even if a user clicks into the text box).

Here I have a choice to handle this in the view model (which would then need to know about the view, which I want to avoid).

I also have some other code like that does things to the UI when the user presses up down left or right on the keyboard (and they only make changes to the view, not the model or viewmodel) and again I'm thinking the best place for these is in the code behind of the view.

So I'm asking if the code only affects the view (e.g. things like cursor movement, selecting all text in a text box etc..., and not the model or view model, is it okay to put it in code behind, rather than elsewhere.

Wondering what is best practise here, or if anyone else has a better suggestion where to put this code.

DermFrench
  • 3,968
  • 13
  • 43
  • 70
  • I'm not a great software designer, so instead I focus on 3 things: ease of testing; eliminating duplication; naming things well. Which approach gets you those things? – Jay Bazuzi Jan 09 '14 at 03:49

5 Answers5

21

So I'm asking if the code only affects the view (e.g. things like cursor movement, selecting all text in a text box etc..., and not the model or view model, is it okay to put it in code behind, rather than elsewhere.

Not only it is OK, but it is strongly encouraged. MVVM is not here for you to write thousands of ugly lines of code in ViewModels, it's here to make the code testable and to introduce a separation of concerns.

If it's purely related to the view (your "focus" example is a perfect example), then just write it in the code behind.

ken2k
  • 48,145
  • 10
  • 116
  • 176
8

If the behavior is UI related only, then you should not put it in the ViewModel. The highlighting example you gave is a good example of such a case. Having said that, I would suggest you avoid repeating your code by (for example) creating a custom control that highlights the text when it has the focus. This way, you can reuse the control in as many views as you can, your views stay free of codebehind, and if you optimize your control, the optimizations happen across the board.

EDIT:

In light of Ravi's answer, Behaviors are also a way to introduce UI related logic while leaving the View free of codebehind. However, if you are finding yourself repeatedly declaring the same controls with the same behaviors, in my opinion it is better to create a control that incorporates the behavior.

That being said, if said UI logic is going to appear only once in one view, you may consider putting it in codebehind. Although it is quite rare to know in advance that you are not going to need that logic elsewhere.

EDIT:

I think @ken2k 's use of strong encouragement refers to not putting it in the ViewModel, which I also advocate. UI logic should be implemented in the View, as he says. Now, there are a few ways of doing that. One of these is coding it directly in your codebehind, which can lead to repetitious code and maintenance issues. Also, if you employ unit testing, it could put you in a difficult spot. The second is coding such logic into behaviors, which is a good way to encapsulate UI code. You can then unit test the behavior to make sure it works OK. However, you can find (as I did, in many projects) that you have started to pepper every TextBox in your XAML's with behavior tags. If that starts to happen, I would (and have) create a 'HighlightedTextBox' control and use that in my XAML. In summary, my suggestion does not contradict ken2k's, but is a pointer in the direction of resolving some issues you may have when placing logic for your View.

Boluc Papuccuoglu
  • 2,318
  • 1
  • 14
  • 24
  • what do you think of ken2k's answer where he is saying it is strongly encouraged? – DermFrench Jan 02 '14 at 15:12
  • My response comment was a bit too long, so I re-edited my answer. Please see above. – Boluc Papuccuoglu Jan 02 '14 at 16:00
  • 4
    My preference for simple repetitive UI behaviors like [text highlighting on focus](http://stackoverflow.com/a/7810516/302677) is to use Attached Properties :) – Rachel Jan 02 '14 at 17:37
  • @Rachel, Actually most behaviors make use of Attached Properties in their implementation – Boluc Papuccuoglu Jan 02 '14 at 19:18
  • @BolucPapuccuoglu Yes that's true, I was thinking of something else when I wrote that. Leaving the link though since it seems related to the question and the OP may find it useful. – Rachel Jan 02 '14 at 19:20
5

Using Custom controls as @Boluc Papuccuoglu suggested, is good option but before using that i want you to take look here Behaviors in WPF introduction

Ravi
  • 853
  • 8
  • 17
3

It is strongly recommended to have all your view stuff logic at one place. Instead of polluting ViewModel you should always keep View stuffs in XAML and code behind.

ViewModel responsibility is to contain only data part which can be unit tested. With UI stuff in ViewModel, you will make it hard to be unit tested.

As per link here at MSDN, definition of code behind:

Code-behind is a term used to describe the code that is joined with markup-defined objects, when a XAML page is markup-compiled.

As you can see, code behind is partial class of your view. One half is declared via x:Class attribute at root element and other half in form of code behind. So, as per me all UI stuff should be at one place and you should not think twice before placing the view stuff in code behind. (that's what it is meant for). MVVM never meant design without any code behind.

Also ViewModel responsibility is to just provide data to your view via data binding. It should never be aware of UI stuff.

Read more about it here - Code behind and XAML in WPF.

Rohit Vats
  • 79,502
  • 12
  • 161
  • 185
-1

How much of your code do you want to unit test? If your view can trigger a command when a control gets focus and your view model can programatically fire an event to highlight the text in that control then you have everything you need to unit test that behaviour with mocked objects. And even if you don't want to unit test (or can't because the bean-counters at your company won't give you the time/budget to do so) then placing that functionality in attached behaviours means they can be used elsewhere. I'm not quite the hard-core MVVM purist as some others on this site but I can honestly say that even in the largest enterprise applications I've worked on I've never once seen a case where WPF code-behind was absolutely required.

Mark Feldman
  • 15,731
  • 3
  • 31
  • 58