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