1

Can anyone clarify these terms please.
I find them to be very vague or context-dependent.

For example we have a VM with the items list. The selection affects not only the accesibility of the buttons (i.e. command can execute) but also the behavior of VM: it matters one ore several items need simultaneous editing.

The second example is the process of creating a new item.
After user provided data we add item to items collection thus inserting it in the list and want to make it selected and focused. Now we do this by introducing IsSelected and IsFocused properties for item's VM. The real job is done by the View via bindings, attached properties and behaviors.

Some members of our team insits that adding such kind of properties (IsVisible, IsSelected, IsFocused an etc.) to VMs brings UI logic to VM and that is not a good practice because UI and presentation logic are mixed.

For me following patterns is importand but more important not to repeat myself. I prefer bindings and few lines in codebehind without casting DataContext to concrete VM's type, calling VM's methods and so on.

Nevertheless I do not like HolyWars and admit I can be wrong due to misunderstanding of these two terms and the criteria of separation one from the other.

Pavel Voronin
  • 13,503
  • 7
  • 71
  • 137
  • http://en.wikipedia.org/wiki/Presentation_logic Presentation seems like UI logic to me http://en.wikipedia.org/wiki/User_interface – kenny Feb 01 '13 at 09:57

1 Answers1

3

I think it's important to put presentation logic in the VM and have properties like IsEnabled on it as this makes it testable. This also reduces the complexity of your views, subsequently reducing the amount of code that cannot be unit tested.

Furthermore, I would be interested in any references your colleagues might have on why presentation logic in VMs is not best practice. IMHO the UI is part of the presentation layer and the purpose of the VM is to model the view. Therefore, it appears natural to put presentation logic here.

Additional Edit:

From Implementing the MVVM Pattern

The view's responsibility is to define the structure and appearance of what the user sees on the screen. Ideally, the code-behind of a view contains only a constructor that calls the InitializeComponent method. In some cases, the code-behind may contain UI logic code that implements visual behavior that is difficult or inefficient to express in Extensible Application Markup Language (XAML), such as complex animations, or when the code needs to directly manipulate visual elements that are part of the view. You should not put any logic code in the view that you need to unit test. Typically, logic code in the view's code-behind will be tested via a UI automation testing approach.

David Osborne
  • 6,436
  • 1
  • 21
  • 35
  • The are not sure that controlling selection or focus from VM is a presentation logic. There is why I ask about clarification for these terms. – Pavel Voronin Feb 01 '13 at 09:39
  • They could be right. But I think that putting this logic in the VM makes testing possible and easier. Especially so if control state is dictated by business logic. – David Osborne Feb 01 '13 at 09:51
  • @voroninp I agree David, things like controlling the selection and focus are UI/Presentation logic. VMs are for 'controlling' the interactions between the domain and the UI. Are they suggesting putting that code in the view itself? – kenny Feb 01 '13 at 09:53
  • Let's be clear, I'm not suggesting that the VM 'controls' control state. I'm suggesting that the VM models control state via properties like IsEnabled, etc. How else would you test that a control was enabled if a certain business rule was applied? The view just mirrors the state of VM via binding or code. – David Osborne Feb 01 '13 at 10:05
  • @voroninp with the MVVM pattern it's quite natural to put Is* properties on the VM for the view to bind to. – kenny Feb 01 '13 at 10:09
  • @kenny I know =) But this sounds not very persuasive for them. I think it's the question of working with MVVM in practice – Pavel Voronin Feb 01 '13 at 10:10
  • Sometimes, developers are there own worst enemies... Can't you find new colleagues with more open minds? !-) – David Osborne Feb 01 '13 at 10:13
  • @voroninp quite strange, if your team buying into doing MVVM which having View Models at all seems to imply. ;) – kenny Feb 01 '13 at 12:02
  • @kenny Newcomers are very active... too active I'd say =) – Pavel Voronin Feb 01 '13 at 12:10