2011-04-06 6 views
8

La nostra applicazione è un progetto di grandi dimensioni con molti moduli e visualizzazione. La finestra principale ha una barra multifunzione e stiamo cercando il modo migliore per integrare la barra multifunzione nell'applicazione.Utilizzo di Microsoft (o altro) nastro con progetto grande e MVVM

Ho creato un servizio che moduli possono essere registrati da una vista per aggiungere elementi nastro rilevanti per loro e, inoltre, qualsiasi istanza di visualizzazione principale può fornire i propri elementi nastro rilevanti per tale istanza. a RibbonItem è una piccola classe che astragga le opzioni di un elemento a nastro e ha principalmente titolo, descrizione, comando, UIType e ChildItems. Il servizio è incaricato di ricostruire il nastro quando cambia la vista principale.

Un mio collega pensa che questo sia un MVVM errato, in quanto gli utenti devono progettare la propria vista a nastro nel codice C# e non in XAML e inoltre afferma che sarebbe difficile in questo modo rendere un gruppo di elementi disabilitato o abilitato contemporaneamente, poiché ogni comando di questi elementi dovrà aggiornare separatamente CanExecute. Invece, ha suggerito di avere i principali file Ribbon View e ViewModel, in cui ogni sviluppatore che desidera aggiungere un pulsante a nastro per il suo modulo o vista dovrebbe aggiungerli nel View XAML e aggiungere un comando rilevante nel ViewModel. Inoltre, i VisualState verranno utilizzati per determinare quali elementi verranno visualizzati o abilitati in base alle modifiche apportate a ViewModel (come cambio di visualizzazione o modifica della selezione). Non mi piace questa soluzione, soprattutto perché tutti gli sviluppatori dovranno mettere a conoscenza dei loro moduli una volta che il file è grande.

Si noti che alcuni elementi nella barra multifunzione (ad esempio Opzioni, Esci) sono comuni all'intera applicazione, mentre alcuni sono pertinenti a un dominio specifico dell'applicazione e alcuni sono rilevanti solo per una vista specifica.

Modifica: Credo che la mia domanda principale sia qual è il modo consigliato per consentire a più team di sviluppo di integrarsi su un singolo nastro? Dovremmo avere un singolo RibbonView e un singolo RibbonViewModel che conterrà tutti gli elementi possibili in un nastro, e ogni squadra aggiungerà i suoi elementi a questi V/VM e definirà anche la logica su quando mostrarli (probabilmente usando lo stato visivo) ? Oppure permettiamo a ogni view, al modello di vista o al modulo di registrare elementi del nastro (all'interno del proprio codice C#) rispetto a un servizio e il servizio rende quindi il nastro necessario quando la vista attiva cambia con tutti gli elementi registrati per quel tipo? O c'è un modo migliore per raggiungere questa integrazione?

Cosa ne pensi? Hai un'idea o un'opinione migliori su come gestire la risorsa single ribbon comune a più sviluppatori?

Grazie, splintor

+1

Bene, ViewModels non deve "sapere" nulla sulla barra multifunzione. Non dovrebbero controllare ciò che è e non è visualizzato nella barra multifunzione. La vista dovrebbe rispondere ai cambiamenti di stato del ViewModel per determinare cosa e cosa non mostrare. – Will

+0

Che cosa significa "ricostruire il nastro"? Se hai diversi nastri per viste diverse, non è una buona pratica, perché il nastro deve essere solo uno. Il tuo collega ha ragione. E permetterei a un solo sviluppatore di cambiare il nastro. – vorrtex

+0

Questa è un'applicazione a schede, con molti tipi di schede: ogni tipo ha i propri comandi a nastro. Invece di avere tutti gli elementi nel nastro, ho pensato di ricostruire il contenuto del nastro con gli elementi pertinenti quando le modifiche alle schede saranno più semplici. A differenza di quello che dici, il mio collega dice che tutti modificano la propria parte nei file della barra multifunzione, poiché ogni sviluppatore sa come vuole che i suoi elementi della barra multifunzione guardino. Non mi piace davvero l'idea di avere due file di grandi dimensioni che centralizzano la conoscenza dell'intera applicazione e dei suoi schermi: è una grande applicazione e dobbiamo decomponerla il più possibile. – splintor

risposta

1

Sono d'accordo con il commento di Will, il vostro ViewModel non deve preoccuparsi o sapere come viene eseguito il rendering o se i progettisti mai decidono di cambiare quel che ne risulta.

Un ViewModel deve contenere solo tutte le informazioni richieste per il livello presentazione per renderlo.

Così il ViewModel dovrebbe avere tutte le proprietà a cui la barra multifunzione deve legarsi per funzionare. Quindi puoi usare Resources.xaml o qualche altra strategia per presentarlo.

Facendo un salto nel buio vorrei provare qualcosa di simile per i ViewModels:

public interface IMenuViewModel : INotifyPropertyChanged 
{ 
    ICommand Command {get;} 
    string Title {get;} 
    string Description {get;} 
    UIType Type {get;} 
    IList<IMenuViewModel> ChildItems {get;} 
} 

vorrei allora probabilmente creare una classe astratta che fornisce strumenti INotifyPropertyChanged con una classe di raccolta degli attrezzi INotifyCollectionChanged di prendersi cura di il codice idraulico.

Vorrei quindi probabilmente fare qualcosa di simile nel Resources.xaml

<DataTemplate DataType="{x:Type vm:IMenuViewModel}"> 
    <StackPanel> 
    <Button Command="{Binding Command}" Content="{Binding Type}"/> 
    <ItemsControl ItemsSource="{Binding ChildItems}"/> 
    </StackPanel> 
</DataTemplate> 

per fornire una visualizzazione predefinita per i tuoi ViewModels

e poi tutto qualcuno deve fare per creare una voce nel vostro nastro bar è

1) Implementare IMenuViewModel

2) Eventualmente aggiungere un'altra voce DataTemplate nella vostra resources.xaml se wa nt il loro widget reso in modo diverso così:

<DataTemplate DataType="{x:Type vm:FooViewModel}"> 
    <v:FooView /> 
</DataTemplate> 

Spero di non aver scavato a fondo su come implementerei.

Il punto principale è che un ViewModel dovrebbe esporre solo le proprietà necessarie per la vista di fare il suo lavoro (che sta rendendo la ViewModel), non per la ViewModel per fare il lavoro o di cura come si fa.

+0

Penso che tu abbia perso il mio punto principale: aggiungerò un aggiornamento per chiarire la mia domanda. – splintor

Problemi correlati