1

It's been on my mind for a while. Let's say that I have a simple app made in WPF with single rectangle inside a canvas. I can move this rectangle with Canvas.Left and Canvas.Top on mousemove. But let's say I want also to change colour of this rectangle, based on some calculation and change its width and height. I can do that by binding dependency properties from my viewmodel. However, as my project progress, my viewmodel became bigger and bigger. I would love to encapsulate some of its logic in separated objects. So i create a class for my Rectangle, containing properties like background, posX, posY, width and height.

The thing is, all those properties are view specific. In other words, this object isn't belonging to buisness logic of application (If I understand those concepts well, I'm still learning). So the question is, where I should contain class of this object? In model or in a helper layer of MVVM.

Thanks for answers.

clearTaoe
  • 37
  • 4
  • 1
    You should have model `Rectangle` with posX, posY, color. In Vm you have implementation of your model with bindings to the view. If your viewmodel becomes too big you can refactor elements that are more common, such us e.g. `CalculatePositionOffset` could be in other class if it can calculate pos offset for other things too. Sometimes vm's are big, that just how it is. – FCin Aug 24 '17 at 17:15

1 Answers1

5

The view model exposes properties that the view binds to, like for example your background, posX, posY, width and height properties. That's what the view model is for. The actual business logic has nothing to do with the presentation and belongs to the model.

So your "view specific" properties certainly belong to the view model class. These properties are typically not dependency properties but rather simply CLR properties though but that's a story of its own:

INotifyPropertyChanged vs. DependencyProperty in ViewModel

mm8
  • 163,881
  • 10
  • 57
  • 88