Come devo gestire il multi-tasking in un'applicazione WPF?

1

Nella maggior parte delle applicazioni CRM multi-tasking che ho visto, MdiWindow viene utilizzato per consentire agli utenti di aprire più finestre contemporaneamente.

Ma MdiWindow non sembra essere comunemente usato in WPF. Guardando attraverso Codeplex, ho trovato solo un progetto MdiWindow abbandonato.

In alcune delle applicazioni CRM basate su WPF che ho visto, creano un dashboard e consentono solo agli utenti di lavorare su una cosa alla volta.

Qual è il modo migliore per gestire il multi-tasking in un'applicazione WPF? C'è un'alternativa migliore a MdiWindow in WPF?

    
posta King Chan 10.02.2012 - 18:25
fonte

3 risposte

1

Normalmente il design che utilizzo funziona come TabControl : c'è un'area di navigazione e un'area di contenuto

Penso che sia perché non mi piace ingombrare il mio spazio di lavoro con molte finestre per la stessa applicazione. Preferirei avere una singola istanza di applicazione contenente tutto ciò su cui sto lavorando.

Trovo anche che sia più semplice gestire Views e Dialog con il pattern di progettazione MVVM. Di solito ho un ShellViewModel contenente le viste attualmente aperte, un elenco di visualizzazioni disponibili e la vista attualmente attiva.

    
risposta data 10.02.2012 - 18:38
fonte
1

La tua domanda, a quanto ho capito, sembra riguardare la GUI Design in generale piuttosto che il WPF in particolare.

Per presentare le informazioni secondarie, hai le opzioni di:

0 - MDI Windows (consente la presentazione e l'organizzazione automatica di più finestre contemporaneamente)

1 - Finestre ancorate come in VS2010 (consente all'utente di organizzare lo spazio di lavoro in modo che possa concentrarsi sulle finestre specifiche desiderate)

2 - Schede come suggerito da Rachel (questo mostra solo parte delle informazioni e nasconde il resto)

3 - Procedure guidate

4 - Display a fisarmonica (un po 'raro ma che consente di espandere solo le bande di interesse)

Esistono strumenti di terze parti che forniscono tutte le funzioni di cui sopra in modi chiari.

Alcuni dei punti chiave da prendere in considerazione quando si seleziona l'interfaccia da considerare:

A - L'utente ha davvero bisogno di vedere / interagire con tutte queste informazioni insieme o contemporaneamente? Ricorda che nessuno può digitare o guardare (attivamente) a 2 finestre contemporaneamente. Il tuo operatore dovrebbe visualizzare le informazioni necessarie per prendere una decisione aziendale insieme in una visualizzazione quando possibile. Altre informazioni (secondarie) potrebbero essere ottenute tramite la navigazione in finestre modali. La maggior parte delle persone non sarà in grado di guardare 40 diversi campi sullo schermo per prendere una decisione o intraprendere un'azione. Normalmente, nelle applicazioni aziendali, un processo è composto da passaggi e ogni fase ha i propri dati. Dovresti essere in grado di completare un processo di business senza dover visualizzare più finestre contemporaneamente. Dovresti valutare la navigazione tra le finestre come alternativa (come in (3)).

B - Le informazioni presentate in ogni finestra sono indipendenti dalle altre finestre aperte? Altrimenti, ti dirigerai verso una programmazione un po 'complessa. Per rendere tutte le finestre rispondono a un cambiamento in una finestra può essere difficile. Stai attento.

Per riassumere, il processo aziendale, il volume di dati richiesto, la facilità d'uso e la facilità di implementazione dovrebbero essere tutti elementi nella scelta. Ad esempio, se la modifica delle informazioni in una finestra provoca la modifica di altre finestre (o schede), il programma potrebbe essere complesso e probabilmente si desidera evitare di farlo.

    
risposta data 11.02.2012 - 00:44
fonte
0

Piuttosto che reinventare la ruota, potresti voler utilizzare un framework MVVM, come Caliburn.Micro, che si occupa di un sacco di plumbing durante la creazione di un'applicazione shell (o dashboard):

link

    
risposta data 26.07.2016 - 21:47
fonte

Leggi altre domande sui tag