2010-10-25 6 views
7

Ho una vista che ha un elenco di elementi legati al mio ViewModel (pattern MVVM).MVVM. L'aggiunta di codice a View è giustificata in alcuni casi?

Diciamo che sembra che:

<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> 

Quando l'utente aggiunge qualcosa alla MessageLog (c'è una proprietà MessageLog in VM) Voglio scorrere automaticamente alla voce più recente.

In altre parole, voglio solo spostare la barra di scorrimento automaticamente quando l'utente digita un messaggio e premere Invio (qualcosa come Skype).

Il binding su MessageLog funziona come previsto e l'elemento viene aggiornato sulla vista. (Sono contento di questo e voglio lasciarlo così)

Mi chiedo se usando l'approccio del pattern MVVM, posso ancora implementare un codice di scorrimento automatico dietro il file della vista? Sembra essere abbastanza logico in quanto il comportamento di scorrimento non ha nulla a che fare con la VM e ViewModel non sa nulla della Vista. È giusto? Sto andando nel modo giusto o mi manca qualcosa?

In generale, quando aggiungere un'implementazione a una vista ha senso?

risposta

9

Sì, questo è perfettamente accettabile. Poiché la logica qui è correlata al 100%, non c'è alcun problema con l'aggiunta alla vista.

MVVM consiste nel separare la logica di applicazione dalla logica View, non necessariamente nello stripping del 100% del codice dalla vista.

Detto questo, ci sono alternative al codice dietro per questo. Proprietà allegate (o Comportamenti) sono una grande opzione per attività come queste: hanno il grande vantaggio di essere riusabili in altre viste in seguito, quindi non si reinventa più tardi se si decide di volere lo stesso comportamento in altre parti del proprio Utente Interfaccia.

+0

Qualsiasi esempio delle proprietà/comportamenti allegati, sarei interessato a saperne di più su questo! –

+2

@pete: ho scritto un articolo che descrive l'utilizzo di un comportamento: http://reedcopsey.com/2009/10/09/using-behaviors-to-allow-the-viewmodel-to-manage-view-lifetime-in-mv -vm/ –

+2

@pete: Nishant Sivakumar lo ha portato su un supporto fissato in dotazione. Vedi: http://reedcopsey.com/2010/04/15/attached-property-port-of-my-window-close-behavior/ –

Problemi correlati