MVVM Is adding code to view justified in some cases?

Question

I have a view in which there is a list of elements attached to my ViewModel (MVVM template).

Let's say it looks like this:

<ScrollViewer Width="Auto" Height="Auto"> <ItemsControl ItemsSource="{Binding Path=MessageLog}" Grid.IsSharedSizeScope="True" ScrollViewer.CanContentScroll="True"> <ItemsControl.ItemTemplate> <DataTemplate> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="150" SharedSizeGroup="FullName"/> <ColumnDefinition Width="*" SharedSizeGroup="MessageLog"/> </Grid.ColumnDefinitions> <StackPanel> <TextBlock Text="{Binding Path=PostedBy.FullName}" /> <TextBlock Text="{Binding Path=DatePosted}" /> </StackPanel> <TextBlock Grid.Column="1" Text="{Binding Path=MessageLog}"/> </Grid> </DataTemplate> </ItemsControl.ItemTemplate> </ItemsControl> </ScrollViewer> 

When the user adds something to the MessageLog (there is a MessageLog property in the VM), I want to automatically scroll to the last item.

In other words, I just want to automatically move the scroll bar when the user types a message and presses the enter button (something like Skype).

The binding to MessageLog works as expected, and the item is updated in the view. (I am pleased with this, and I want to leave it like that)

I am wondering if using the MVVM template template, can I still implement automatic scrolling in the code behind the View file? This looks logical, since the scroll behavior has nothing to do with the VM, and the ViewModel knows nothing about the view. It is right? Am I going right or is something missing?

Generally speaking, when adding an implementation to a view makes sense?

Answer 1

Yes, that’s perfectly acceptable. Since the logic here is 100% View related, there is no problem adding it to the View.

MVVM is dedicated to separating application logic from your view logic, not necessarily about removing 100% of the code from your view.

So there are alternatives to code for this. Attached properties (or Behaviors) are a great option for such tasks - they have the great advantage of being reused in other views later, so you won’t reinvent it later if you decide you want the same behavior in other parts of your user interface .